HomePlug GP Specification



Access CoexistenceNote: This chapter is informative until the HomePlug Access (BPL) specification is complete, at which point this section may be revised.HomePlug AV provides both time- and frequency-based coexistence of In-Home and Access systems. Access systems are sometimes referred to as Broadband over Power Lines (BPL) in other parts of this specification. This chapter describes how In-Home Networks and an Access Network can coexist. It describes the Time Division Access Coexistence mechanisms that extend the Neighbor Network coordination described in REF _Ref95379745 \r \h \* MERGEFORMAT Chapter 8 for access coexistence. It also describes the Frequency Division Access Coexistence mechanism. The features in this chapter are optional. However, coexistence with a HomePlug BPLN is mandatory using the Neighbor Network Coordination features described in REF _Ref95353938 \r \h \* MERGEFORMAT Chapter 8.Flexible Time Division Access Coexistence XE “ Access coexistence:flexible time division access" The In-Home and Access Networks coexistence problem is slightly different than the (neighbor) In-Home Networks coexistence problem in that a STA (called Gateway STA) may belong to both an In-Home Network and the Access Network. As a result, additional requirements are placed on the Gateway STAs. Moreover, a Gateway STA may be able to obtain a CFP for its communication with the Access Network from either the Access Network or the In-Home Network it belongs to.Terminologies The following terms shall be used when discussing Access Network coexistence.Access CCo: An Access CCo is a CCo that is controlled and owned by the Access Provider to provide services to Access Users (i.e., customers). An Access CCo maintains the Access Network and transmits a Beacon once every Beacon Period. Gateway STA: A Gateway STA is a STA located inside the house of an Access User. The Gateway STA may belong only to the Access Network. However, if the Access User has its own In-Home Network, the Gateway STA may belong to both the Access Network and the In-Home Network.Access Network: An Access Network consists of an Access CCo and Access STAs from all Access Users. A separate NEK is assigned by the Access CCo to each Access User. Note: An Access User may have one or more Access STAs. Therefore, privacy can be protected between different Access Users.In-Home CCo (or simply CCo): An In-Home CCo is a CCo that is owned by a user to set up an In-Home Network for delivery of audio, video, and data within the house. An In-Home CCo transmits a Beacon once every Beacon Period. Note: An In-Home CCo may also be a Gateway STA.In-Home Network: An In-Home Network consists of an In-Home CCo, In-Home STAs (or simply STAs), and optionally one or more Access STAs, all owned by the same user.AssumptionsIt is assumed that the Access CCo and the In-Home CCo(s):Are within range of each other (that is, one is able to detect and decode the Beacon of the other).Are operating in Coordinated Mode of the Neighbor Network coordination.Access CCo Requirements XE “ Access coexistence:CCo requirements" The Access CCo shall support the use of multiple network membership keys (NMKs) and multiple network encryption keys (NEKs). Each Access User should be assigned a different NMK and NEK during the association and authentication process. Therefore, the minimum number of NMKs and NEKs that the Access CCo must be able to handle is equal to the number of active Access Users in the Access Network. The Access CCo shall assign a single NID for all of its active Access Users in the Access Network, so at most one NMK will be the default NID derived from the NMK.The Access CCo shall support unencrypted association from Gateway STAs. It shall also support the use of a high-level application (e.g., secured HyperText Transfer Protocol (HTTP)) to validate the identity of an Access User/Gateway STA.The Access CCo shall interpret the BENTRYs (refer to Section ? REF _Ref95378979 \r \h \* MERGEFORMAT 4.4.3.15.4.1 and Section REF _Ref95378316 \r \h \* MERGEFORMAT 4.4.3.15.4.2) in addition to the Region’s BENTRY (refer to Section ? REF _Ref140334799 \r \h \* MERGEFORMAT 4.4.3.15.4.3) of the Beacons of the In-Home CCo. This is required when the Access CCo is using bandwidth owned by the In-Home CCo (refer to Section ? REF _Ref95379843 \r \h \* MERGEFORMAT 10.3.2).Access STA Requirements XE “ Access coexistence:STA requirements" A Gateway STA shall support the following additional functionalities to communicate with an Access CCo:It shall support unencrypted association with the Access CCo.It shall support non-default NIDs (i.e., an NID associated with an NMK that is not derived from that NMK).It shall support the use of a high-level application (e.g., secured HTTP) to prove the identity of the Access User to the Access CCo.If an Access STA belongs to both the Access Network and an In-Home Network, it shall support the following additional functionalities:It shall support the use of at least two NEKs, one for point-to-point communication with the Access CCo and the other for communication within the In-Home Network. It shall support the use of two TEIs, one assigned by the Access CCo for use in the Access Network and the other assigned by the In-Home CCo for use in the In-Home Network.Sharing of Resource between Access Network and In-Home Networks XE “ Access coexistence:sharing resources" A Gateway STA may be able to communicate with the Access CCo using a time interval that is owned by the In-Home CCo. In this case, the In-Home CCo shall continue to specify a CFP and the Access CCo shall continue to specify a Stayout Region during that time interval in their Beacons. However, the Access CCo may be allowed to transmit in that time interval. For more information, refer to Section ? REF _Ref95379843 \r \h \* MERGEFORMAT 10.3.2.Association, Authorization, and Authentication ProceduresAssociation Procedure XE “ Association procedure" XE “ Procedure for:association" The association process of a Gateway STA is similar the procedure described in Section ? REF _Ref101689014 \r \h \* MERGEFORMAT 7.3, with some minor modifications.The Gateway STA shall scan for Beacons from the Access Network. The Access field in the Frame Control indicates whether the Beacons are from the Access Network or the In-Home network (refer to Section REF _Ref111996542 \r \h \* MERGEFORMAT 4.4.1.3). The Gateway STA decodes the Beacon and locates the CSMA Region. The Gateway STA then sends an unencrypted association message to the Access CCo in the CSMA Region. It shall support the use of a high-level application to prove the identity of the Access User to the Access CCo.If Beacons from the Access Network cannot be detected, the Gateway STA shall never attempt to establish an Access Network. Instead, it shall continue to scan for Beacons from Access Networks.Furthermore, if the Gateway STA is configured to join both the Access Network and In-Home Network, it shall scan for Beacons from In-Home Networks as well. The Gateway STA shall proceed using the procedure described in Section REF _Ref101689014 \r \h \* MERGEFORMAT 7.3 for joining an In-Home Network. The Gateway STA may become the CCo of the In-Home Network if it is the first STA to start up in the In-Home Network.Authorization and Authentication Procedures XE “ Authorization procedure" XE “ Procedure for:authorization" XE “ Authentication procedure" XE “ Procedure for:authentication" A Gateway STA and an Access Network CCo shall use procedures similar to those described in Section REF _Ref101689014 \r \h \* MERGEFORMAT 7.3 for joining an Access Network. Differences are noted below.First, since the NID used by an Access Network might not be derived from the NMK given to the Gateway STA for that Access Network, a Gateway STA shall use the NID (including the SL) provided to it with the NMK rather than the default NID when scanning for an NID match. The Gateway STA may attempt to associate and authenticate with an Access Network using the Access Network NMK it possesses, even if there is no NID match.The NID to associate with an Access Network NMK is provided in one of two ways. It is either passed across the H1 interface along with the NMK using the APCM_SET_KEY.REQ primitive, or it is included in the CM_SET_KEY.REQ MME with the NMK in the payload of a CM_ENCRYPTED_PAYLOAD.IND MME that uses the DAK of the Gateway STA for payload encryption. In both cases, the Gateway STA shall associate the NID provided with the NMK with that NMK, rather than using the NMK to generate the NID offset to derive the default NID.Once the Gateway STA has the NID and NMK, it shall obtain an NEK and EKS from the Access Network CCo in the manner described in Section REF _Ref140223643 \r \h \* MERGEFORMAT 7.3.3 and Section REF _Ref140298226 \r \h \* MERGEFORMAT 7.10.4.The Access Network CCo will use a different NEK and may use a different NMK for each user. The EKS shall be the same for all users, however, so when a new EKS and NEK is distributed to any user, the EKS must be updated for all users. It is not required that the NEK change for all users, however. When the Access CCo has distributed the new EKS (and possibly, new NEKs) to all users in the Access Network, it shall use the countdown mechanism in Section REF _Ref153786298 \r \h \* MERGEFORMAT 4.4.3.15.4.8 to make the new EKS and NEK(s) effective. Since the NEK is different for every user, but the EKS is the same, the Access Network CCo shall use the MAC address (directly or indirectly through the TEI) of the Gateway STA to disambiguate the EKS when decrypting PBs from it. Likewise, it shall determine which NEK to use when encrypting PBs based on the destination STA’s identity.Since a different NMK may be given to each user, the Access Network CCo shall use the MAC address of the Gateway STA to determine which NMK to use when exchanging messages encrypted with an NMK. It is not necessary to coordinate NMK changes across all sub-AVLNs, so the Beacon-based countdown mechanism is not required.Bandwidth-Allocation Procedure XE “ Access coexistence:bandwidth allocation" XE “ Bandwidth allocation for access coexistence" This section describes the procedure used by a Gateway STA to set up a new CFP Connection to communicate with the Access CCo. The Gateway STA and the Access CCo first exchange the CM_CONN_NEW.REQ and CM_CONN_F messages to set up the Connection. Next, the Gateway STA shall request for bandwidth allocation (i.e., CFP) for the Connection.Depending on whether the existing resource owned by the Access Network and/or In-Home Network is sufficient to support the new Connection, the procedure will involve one of the three scenarios described in Section ? REF _Ref95379931 \r \h \* MERGEFORMAT 10.3.1 through Section ? REF _Ref95379933 \r \h \* MERGEFORMAT 10.3.3.Note: The procedure used by a Gateway STA to set up a new CFP Connection to communicate with another STA that also belongs to the same In-Home Network is the same as the one in Section ? REF _Ref95379974 \r \h \* MERGEFORMAT 5.2.3.1. If the Gateway STA belongs only to the Access Network, the procedure to set up a new CFP Connection is the same as the one in Section REF _Ref95379974 \r \h \* MERGEFORMAT 5.2.3.1, with the Gateway STA treated as the source STA and the Access CCo treated as both the destination STA and the CCo.Using Access Network Resources XE “ Access network resources " In this scenario, the Access Network is able to support the new CFP Connection with its existing resource (see REF _Ref84844438 \h \* MERGEFORMAT Figure 101).After receiving the CM_CONN_F message, the Gateway STA sends the CC_LINK_NEW.REQ message to the Access CCo. The message contains the STEI, DTEI, CSPEC, LLID, and channel estimate to the Access CCo.If the Access CCo can support the new request with its existing share of resource, it shall send the CC_LINK_F message with a successful result code to the Gateway STA. The message contains the GLID assigned to the Link, which will appear in the schedule of the Beacons of the Access CCo.Figure STYLEREF 1 \s 10 SEQ Figure \* ARABIC \s 1 1: CFP Setup in Access Network: Using a Resource from Access Network REF _Ref84919119 \h \* MERGEFORMAT Figure 102 shows an example of the schedules of the Beacons before and after the request is accepted in this scenario.Figure STYLEREF 1 \s 10 SEQ Figure \* ARABIC \s 1 2: Example of Beacon Schedules: Using Resource from an Access NetworkUsing Resource from the In-Home Network XE “ Bandwidth allocation for access coexistence:using resources from the In-Home Networking" XE “ Access coexistence:using resource from the In-Home Network" In this scenario, the Access Network is unable to support the new CFP Connection with its existing resource. However, the In-Home Network is able to support the new CFP Connection with its existing resource (see REF _Ref86205116 \h \* MERGEFORMAT Figure 103).If the Access CCo cannot support the new CFP Connection with its existing resource, the Access CCo shall send the CC_LINK_F message with an unsuccessful result code to the Gateway STA. The result code shall indicate that the Gateway STA should attempt to obtain resource from its own In-Home Network.The Gateway STA shall then send the CC_ACCESS_NEW.REQ message to its In-Home CCo to request for resource.If the In-Home CCo can support the request using its existing share of resource, it shall reply with the CC_ACCESS_F message with a successful result code to the gateway STA. The message contains the GLID that the In-Home CCo has assigned for the request. (The case where the In-Home CCo cannot support the request is considered in Section ? REF _Ref95379933 \r \h \* MERGEFORMAT 10.3.3.)The Gateway STA shall then send the CC_ACCESS_NEW.IND message with a successful result code to the Access CCo. This message contains the GCID that is assigned by the In-Home CCo for the CFP Link. The GCID will appear in the schedule of the Beacons of the In-Home CCo.The Access CCo shall then reply with the CC_ACCESS_NEW.RSP message to confirm. The Gateway STA shall then send the CC_ACCESS_NEW.RSP message to its own In-Home CCo.For the time interval secured by the Gateway STA from its In-Home CCo, the Access CCo shall continue to specify a Stayout Region in the schedule of its Beacons. (The In-Home CCo shall continue to specify a CFP.) However, the Access CCo shall interpret the Schedule message of the In-Home CCo and is allowed to transmit in the time interval corresponding to the GLID assigned. Figure STYLEREF 1 \s 10 SEQ Figure \* ARABIC \s 1 3: CFP Setup in Access Network: Using Resource from the In-Home Network REF _Ref84919350 \h \* MERGEFORMAT Figure 104 shows an example of the schedules of the Beacons before and after the request is accepted in this scenario.Figure STYLEREF 1 \s 10 SEQ Figure \* ARABIC \s 1 4: Example of Beacon Schedules: Using Resource from In-Home NetworkUsing Neighbor Network Coordination XE “ Bandwidth allocation for access coexistence:Neighbor Network coordination" XE “ Neighbor Network:access coexistence " XE “ Access coexistence:using Neighbor Network coordination" In this scenario, the Access Network and the In-Home Network are unable to support the new CFP Connection with their existing resource. Neighbor Network coordination is used to attempt to increase the share of resource used by the Access Network to support the Connection (see REF _Ref84847846 \h \* MERGEFORMAT Figure 105).Continuing from Section ? REF _Ref95379843 \r \h \* MERGEFORMAT 10.3.2, if the In-Home Network cannot support the new CFP Connection with its existing resources, it shall send the CC_ACCESS_F message with an unsuccessful result code to the Gateway STA. The Gateway STA shall then notify the Access CCo of the result using the CC_ACCESS_NEW.IND message with an appropriate result code. If the Access CCo decides to initiate Neighbor Network coordination to try to increase its share of resource for supporting the new Connection, it shall respond with CC_ACCESS_F, requesting the Gateway station to resend CC_LINK_NEW.REQ after one second.Note: It is possible that the Neighbor Network coordination might not be complete in one second. In such cases, the CCo may hold the CC_LINK_F until a decision can be made.If the Access CCo is able to obtain extra resource to support the new CFP Connection, it shall accept the subsequent CC_LINK_NEW.REQ by sending a CC_LINK_F, indicating a success. Otherwise, it shall respond with a CC_LINK_F to indicate failure.Figure STYLEREF 1 \s 10 SEQ Figure \* ARABIC \s 1 5: CFP Setup in Access Network: Using Neighbor Network Coordination REF _Ref84919469 \h \* MERGEFORMAT Figure 106 shows an example of the schedules of the Beacons before and after the request is accepted in this scenario.Figure STYLEREF 1 \s 10 SEQ Figure \* ARABIC \s 1 6: Example of Beacon Schedules: Using Neighbor Network CoordinationBandwidth Release Procedure XE “ Access coexistence:bandwidth release" XE “ Bandwidth release for access coexistence" The procedure for releasing an allocated bandwidth is similar to the case in Section REF _Ref157887198 \r \h \* MERGEFORMAT 8.3.8, except when the scenario in Section REF _Ref95379843 \r \h \* MERGEFORMAT 10.3.2 is used to request the bandwidth in the first place (that is, except when the resource is owned by the In-Home Network). This case is described in this section.Either the In-Home CCo or the Gateway STA may initiate the bandwidth release. The Access CCo shall never initiate the bandwidth release if the bandwidth used is owned by the In-Home CCo. Instead, after the connection teardown is performed, the Gateway STA shall initiate the Link release. REF _Ref85016212 \h \* MERGEFORMAT Figure 107 shows the MSC when the procedure is initiated by the Gateway STA after it and the Access CCo have performed the connection teardown. Figure STYLEREF 1 \s 10 SEQ Figure \* ARABIC \s 1 7: Bandwidth Release Initiated by Gateway STA REF _Ref85016286 \h \* MERGEFORMAT Figure 108 shows the MSC when the procedure is initiated by the In-Home CCo.Figure STYLEREF 1 \s 10 SEQ Figure \* ARABIC \s 1 8: Bandwidth Release Initiated by the In-Home CCoFlexible Frequency Division Access Coexistence XE “ Flexible Frequency Division Access coexistence" XE “ Access coexistence:Flexible frequency division" HomePlug AV provides support for an optional second mode of coexistence with Access Networks through the use of frequency division. Two mechanisms provide this capability:One that leverages an inherent feature of the HomePlug AV PHY.One that uses FDMA Coexistence Management Messages (FCMMs) to negotiate the sharing of the channel.A flexible frequency division option is provided to enable either the HomePlug AV network or an Access Network to use the full channel bandwidth when the other is not present or active. Either network can use FCMMs to request/reserve bandwidth from the other.HomePlug AV stations can optionally use two symbol HomePlug AV Frame Control during Frequency Division Coexistence (refer to Section REF _Ref114042437 \r \h \* MERGEFORMAT 3.2.1).Informative TextPHY ConsiderationsFlexible Frequency Division Access Coexistence (FFDAC) allows coexistence of home and access PLC systems using disparate technologies, as long as these systems can exchange basic messages to negotiate dynamic, flexible sharing of frequency sub-bands. Efficient sharing in frequency domain, however, requires more stringent spectral containment at the transmitter and higher dynamic range and filtering at the receiver compared to time-domain sharing.The HomePlug AV PHY uses windowed OFDM that provides good spectral containment by simply skipping the use of tones within and close to the border of a sub-band that needs to be relinquished to neighboring access networks. Although in this sense FFDAC is straightforward, in order to achieve good performance and efficient use of the bandwidth resource designers need to pay special attention to the following:The signal level of the two networks may be very different at a given point in the medium. For example, the signal from the access station will be typically attenuated by many tens of dBs by the time it reaches a residence, and may be much smaller than a signal from the in-home network. This is known as a near-far scenario. In a near-far scenario, transmitters need to provide much better linearity to avoid jamming the signal of the other system with their out-of-band emissions. They are also likely to need some amount of flexible filtering determined by the transmitter linearity and the required rejection of out-of-band emissions.Even in the presence of perfect spectral containment at the transmitter, the receivers in a near-far scenario need to accommodate signals from the neighboring system that enter the receiver at a much larger level than the desired signal. This set of conditions requires additional linearity and analog filtering in the receiver, possibly in combination with larger resolution requirements in the A/D converter. Additionally, the filtering needs to have programmable pass-bands, stop-bands, and sharp transition bands to maintain flexible sharing and efficient use of the spectrum.FDMA Coexistence Management Messages (FCMMs) XE “ FDMA coexistence management messages " Negotiation of the frequency bands between In-Home and Access Networks is accomplished using Coexistence Management Messages transmitted in HomePlug 1.0.1 delimiters as described in Section REF _Ref109741328 \r \h \* MERGEFORMAT 9.8.4.The FDMA Band Request Message is used to request the start and end frequency of a desired frequency band. This message is specified in Section REF _Ref109741457 \r \h \* MERGEFORMAT 9.8.4.2.7).The FDMA Band Response Message is used to indicate the result (rejected, granted or alternate recommendation) of an FDMA Band Request Message. This FDMA BAND Response Message is specified in Section REF _Ref109741881 \r \h \* MERGEFORMAT 9.8.4.2.8).The Current FDMA Band Usage Message is used to indicate the start and end frequency of the frequency band in current usage. This message is specified in Section REF _Ref109741918 \r \h \* MERGEFORMAT 9.8.4.2.9).Negotiation of the Channel XE "Negotiation of the channel" XE "Channel negotiation " Under normal operation, either an In-Home or access station should operate without transmitting FCMMs, but shall always listen for the HomePlug 1.0.1 Preamble and FCMMs. If an Access Network detects HomePlug 1.0.1 Preambles without detecting valid In-Home FCMMs, it shall begin transmitting Current Band Usage FCMMs.If an Access Network detects In-Home Current Band Usage FCMMs, it shall transmit a Current Band Usage Frequency Division Coexistence Message (FDCM).If an In-Home Network detects an Access FCMM for the first time, it shall transmit an In-Home Current Band Usage FCMM. The In-Home Network shall also begin transmitting FCMMs.If a Frequency Band Request FCMM is received, the other network shall reply with a Frequency Band Response FCMM.Flexible TDM Coexistence with Non-HomePlug Networks XE "Flexible TDM coexistence with non-HomePlug networks" HomePlug AV networks optionally support flexible TDM Coexistence with non-HomePlug AV networks by exchanging information using the HomePlug 1.0.1 delimiters. TDMA Coexistence Message defined in Section REF _Ref109742186 \r \h \* MERGEFORMAT 9.8.4 are used to negotiate the percentage of bandwidth required. Subsequently, Coexistence allocation information described in Section REF _Ref109742256 \r \h \* MERGEFORMAT 9.8.3 is used to indicate the start and end times of the TDMA allocations. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download