while originally conceived to service the needs of home networking taking advantage of the installed coax cable plant to distribute local - area - network ( lan ) content within the home , moca has also been extended to several other applications . in a multi - dwelling unit ( mdu ) it has been envisioned that moca could be used as a point - to - multi - point means of distributing wide - area - network ( wan ) content that arrives to the building over an optical - link to multiple tenants , exploiting the installed coaxial cable in the building . in another application scenario it is intended that moca be used to carry the wan content from a curb - side optical network termination to an individual residence in a point - to - point configuration . these applications impose different rate / range performance requirements on the technology . the systems , methods and apparatus embodied in following disclosure are collectively referred to as ‘ enhanced - moca ’ or emoca , as well as all enhancements and variations which would be apparent to one of ordinary skill in the art . emoca relates to how nodes , may extend their rate and / or range of communication over ‘ legacy - nodes ’ or ‘ moca - nodes ,’ which are nodes specified by either standard described in [ 1 ] or [ 2 ]. emoca nodes should be fully interoperable and compatible with legacy - nodes , realizing enhanced rate and / or range performance while communicating with other emoca nodes . emoca nodes should also realize the performance expected of legacy - moca devices while communicating with legacy moca - nodes . also , the operation of emoca is agnostic to an emoca - node being the nc in the network . in other words emoca allows for complete coexistence with legacy - moca . further , the embodiments of the present invention also realize an emoca - node based on the reuse of parts and components used in the construction of a legacy moca - nodes , making emoca particularly suited as a low - cost , high - value upgrade to moca . the benefits of emoca are primarily realized through a mechanism known as channel - bonding wherein emoca devices make use of a plurality of non - overlapping moca channels from the allowed spectrum depicted in fig2 to communicate with one - another . one of the channels is referred to as the ‘ primary - channel ’ while the other ( s ) are referred to as ‘ secondary - channel ( s )’. the primary - channel hosts the legacy moca - nodes and is used by the nc to transmit control information such as beacons and map - frames , as well as data transmissions between nodes on the network . emoca nodes when transmitting to compatible emoca node ( s ) may augment their transmission through the use of the secondary channel ( s ) using the increased bandwidth for realizing one or a combination of the following benefits improving rate and / or range : ( 1 ) additional bandwidth for higher aggregate throughput through channel - multiplexing ; ( 2 ) frequency - diversity for robust transmission ; and ( 3 ) reduced constellation - order for reduced transmit power / enhanced range operation . for simplicity sake , in the ensuing description unless otherwise specified , emoca shall be described in the context of a network with a single primary - channel and a single secondary - channel . however , as would be apparent to one skilled in the art , embodiments of the present invention would be just as applicable to a network of nodes with multiple secondary channels as well . according to an aspect of an embodiment , an emoca - node signals channels that it would use as ‘ secondary - channels ’ as taboo - channels in its beacon or admission - request frame — depending on whether it is the nc or the en . this prevents moca - nodes that receive a beacon from an emoca network from attempting to set up a network on an emoca secondary - channel . in terms of the nodes on the network , ( e ) moca networks are expected to be relatively static in nature —( 1 ) in the multi - dwelling unit ( mdu ) deployment , the network would be managed by the wan provider ; ( 2 ) in the ont deployment , the network is expected to be managed by the wan - provider ; ( 3 ) in the home - network deployment , the network is expected to be managed by either the service - provider or the end - user in the house . it is expected that emoca devices would provide configurability for instance through means of an application - programmable - interface ( api ), or otherwise by which the end - user / network - administrator would be able to define the secondary channel to be used for emoca communications and correspondingly edit the taboo channel - list of the node . in one mode of operation , emoca nodes would use a specific ( configurable ) channel as the secondary channel , this channel being configured as taboo on all nodes in the network . in a mode of operation , the secondary channel would be definable in terms of an offset or a relation with respect to the primary - channel . an emoca network implementing this means of deriving the secondary - channel would perform a frequency scan as would a legacy moca - node and on joining / forming a network on a particular channel would be able to infer the secondary channel to use via a relation common to all emoca - nodes on the network . for example , emoca nodes using the relation : “ secondary channel would be the nearest channel 100 mhz to the right of the primary channel ”, would determine the secondary channel to be 210 if the primary channel was 207 ; 201 if the primary channel was either 213 or 214 . as per [ 1 ], during node admission , an nn sends an admission request to the nc . the nc may either reject the request by ignoring it ; or accept the request through the admission response frame that is broadcast in diversity mode . the admission response frame contains a reiteration of the node_protocol_support field as well as the node_guid fields of every node ( including the nc ) in the network that are repeated as was received by the nc during the node admission of each respective node . also , as per [ 1 ], the first 48 bits of the guid represent the globally unique ethernet mac address of the node . the later 16 - bits are reserved and are set to 0x0000 . according to a mode of operation , an emoca nn signals the number and the position of the secondary channels it is able to ( simultaneously ) use in a 14 - bit ‘ secondary - channel bit - map ’ that occupies the lower 16 - bits of the guid field in the admission request frame . in the admission response frame , the nc broadcasts the guids of all nodes in the network . thus , all emoca nodes interpret the reserved field of the guid in the admission response frame and are aware of the secondary channels to be used while transmitting to an emoca node on the network . fig4 depicts the 64 - bit guid field that is transmitted by emoca nodes as part of their admission request frame . as in the case of legacy - nodes bits 463 through 416 represent the globally unique ethernet mac - id of the device . bits 415 through 402 represent the 14 - bit emoca secondary channel bit map , with 415 representing channel a1 i . e . 201 ; and 402 representing channel d8 i . e . 214 . bits 401 and 400 are reserved for future use . the signaling of the secondary - channel bit - map may also be done via the node_protocol_support field which is treated similarly to the node_guid field by the nc , during the node - admission process . according to a further mode of operation , nodes would be able to negotiate the secondary channel to use after joining the network by signaling over the primary - channel . such communication to negotiate the channel to be used could be facilitated by use of the l2me - protocol described in [ 2 ]; or through means of a proprietary upper - layer protocol signaled via the primary channel and lying above the mac - sub - layer of the moca protocol described in [ 1 ] and [ 2 ]. this mode of operation is further applicable to future enhancements to the moca specification [ 1 ], which may allow for a larger list of available channels than can be accommodated in the signaling scheme depicted in fig4 . according to another mode of operation , it is conceivable that nodes would determine the secondary channel to use after joining the network on the primary channel . the secondary channel to be used could be decided based on scanning the frequency spectrum and characterizing available channels for , among other metrics as apparent to one skilled in the art : ( 1 ) noise - floor measurements ; and ( 2 ) channel profiling between nodes to determine the secondary channel that yields the highest channel - capacity thereby improving aggregate throughput . thus as per the above description , while emoca devices may have different capabilities , distinguished by the number of secondary channels that they can simultaneously support in addition to the primary channel , the location of the secondary channel is common to all devices that support it . as an example , consider a network with a mix of two and three - channel capable emoca devices . devices a and b support one secondary - channel while devices c and d support two secondary channels . devices a and b would have a common secondary - channel bit - map as depicted in fig4 with one of the bits 415 through 402 set . devices c and d would have a mutually - same secondary channel bit - map which would be the super - set encompassing the secondary channel bit - map of devices a and b , as well as one other bit 415 through 402 . emoca nodes employ the primary - channel for transmission of all mac pdus ( ie data and control - frames ), beacons and probes as do legacy moca - nodes , employing the secondary channel for augmenting data transmissions to emoca nodes . in addition to using the secondary - channel for augmenting the data transmission of the primary channel , emoca nodes may also transmit power - control messages and probes as required to facilitate the profiling and consequently the use of the secondary channel . in another aspect , an emoca node that is the nc also transmits beacons on both primary and secondary channels as per the schedule indicated in the map - frame received by the primary channel . this facilitates emoca nns in making power - measurements that are required during the initial transmit power control phase of the node - admission sequence . as per yet another aspect , the beacon transmitted on the secondary channel would have its acf_type field set to ‘ no acf ’ as specified in [ 1 ], thus further preventing any other node from attempting to join / form a network on a secondary channel adopted by the emoca network . thus as per the above description , all schedule related information such as reservation requests and map - frames , which are common to both primary and secondary channels are transmitted on the primary channel . the secondary channel is used to transmit channel - specific information specifically — power - control , probes and loop - back transmissions that are required to facilitate operation of the secondary channel , in accordance with the timing specified by the map - frame received on the primary channel . fig5 illustrates an exemplary representation of channel utilization of the network with respect to time . in the example , the nc and en - x are legacy moca nodes , while en - y and en - z are emoca devices . literal 501 marks the primary - channel while literal 502 , the secondary channel . 511 , 512 and 513 mark reservation requests sent by nodes x , y and z in map - cycle n 505 , which results in the nc transmitting map - frame n + 1 514 which scheduled activity in map - cycle n + 1 506 . as can be seen from the figure , control frames that relate to channel scheduling — 511 , 512 , 513 , 514 , 522 , 523 and 528 , are transmitted on the primary channel 501 . data - frames that are destined to legacy moca - nodes — 521 , 525 and 527 , are transmitted on the primary channel 501 . data - frames that originate from and are destined to emoca nodes —( 526 a , 526 b ), ( 529 a , 529 b ) are transmitted using both the primary - channel 501 and the secondary channel 502 . transmission on both emoca channels follows the schedule published by the map - frame received on the primary - channel . also , channel - specific information such as probes 524 a and 524 b that are used to characterize the channel ( and hence are channel dependent ) are transmitted on both channels 501 and 502 respectively . in order to facilitate the usage of the secondary channel , the front - end device of the secondary channel may also need to be calibrated . additionally , the secondary channel needs to be profiled to determine the transmit power - level , modulation - profile as well as the cyclic prefix length to be used . as calibration is implementation specific and is intrinsic to the device itself , emoca devices should appropriately calibrate their secondary channel front - ends , as they would their primary channel front - ends . during the node - admission process and subsequently during the lmo , moca nodes are required to transmit as well as process transmissions of the type ‘ probe ’ as described in [ 1 ]. emoca nodes transmit ( and receive ) probes on all active channels — primary and secondary , as scheduled by the map - frame 514 received on the primary channel 501 . as per [ 1 ], nodes that have received a transmission of the type ‘ probe ’ are expected to generate responses called ‘ probe reports ’ and send them to the originator of the probe . also as per [ 1 ], depending on the link being profiled and the ‘ link - state ’ of the node , these responses may be relayed through the nc . likewise , as per [ 1 ], during the node - admission sequence , moca - nodes need to additionally transmit and receive frames of type ‘ power - control ’. emoca nodes transmit ( and receive ) power - control frames on all active channels — primary and secondary , as scheduled by the map - frame 514 received on the primary channel 501 . further , as per [ 1 ], nodes that have received a transmission of the type ‘ power control ’ are expected to generate responses called ‘ power control response ’ describing the tx_power_adjustment on the given channel . the originator of the ‘ power control ’ frame is expected to further respond with the ‘ power control acknowledgement ’ frame indicating the max_tpc_adjustment that the node is capable of on the given channel . additionally , emoca nodes implementing the optional ‘ inner - loop power control ’, need to periodically transmit the ‘ power control update ’ frame as defined in [ 1 ]. according to another aspect , an emoca node transmits its secondary - channel probe - reports and power - control response / acknowledgement / update information over the primary channel , by appending to the information contained in probe - report / power - control response / acknowledgement / update frames of the primary channel . as per [ 1 ], the control frame has a generic structure : mocacontrolframe := { mac header frame payload payload crc } in the context of emoca control frames transmitted on the primary channel this is expanded to include a ‘ frame payload ( secondary channel extension )’ field : emocacontrolframe := considering the example of the type - 1 probe report format described in [ 1 ], where among other fields fully specified in [ 1 ], the ‘ frame payload ’ field describes the num_elements parameter which is set to 1 for a unicast report ; and 2 for async - map and bbl report . an emoca - node shall overload the type - 1 probe report using it to convey the secondary - channels &# 39 ; information in the ‘ frame payload ( secondary channel extension )’ which is appended to the ‘ frame payload ’ field that describes the primary channel information . in the context of an emoca type - 1 probe report , the num_elements parameter in the ‘ frame payload ’ field shall additionally signal the interpretation of the ‘ frame payload ( secondary channel extension )’ with num_elements being 1 denoting a ‘ unicast - report ’ and num_elements being 2 denoting a ‘ bbl - report ’ of the secondary channel . in the case of a type - 1 probe report , the frame - payload secondary channel extension contains the following fields : type - 1 probe report frame payload ( secondary channel extension ) := { phy profile preamble type channel_usable max_bins num_of_syms bits_per_acmt_symbol cp_length gcd_bitmask tpc_backoff_major tpc_backoff_minor for j = 0 ; j & lt ; 256 ; j ++{ sc_mod } } likewise , the frame payload ( secondary channel extension ) for the type - 2 and type - 3 probe - reports are as enumerated below : likewise , the frame - payload ( secondary channel extension ) of the power - control response , power - control acknowledgement and power - control update frames are as enumerated below : it would be apparent to one skilled in the art that in the context of an emoca system , some of the parameters of the frame - payload ( secondary channel extension ) may be inferred from the frame - payload field enumerated in [ 1 ]. it is recognized that these may not be transmitted as part of the frame - payload ( secondary channel extension ) and such variants of the frame format are considered to be within the present scope . legacy moca - nodes receiving emoca control frames as per the embodiment above would on determining a valid payload crc , decode the ‘ frame - payload ’ field required for legacy moca operation , ignoring the ‘ frame - payload ( secondary channel extension )’ that is defined for emoca operation , thereby ensuring interoperability . emoca - nodes rely on the map - frame received on the primary channel to coordinate transmission on the primary and secondary channels . critical to realizing efficient use of the medium via emoca would be to split the transmission across primary and secondary channels in a manner that facilitates synchronous transmission and equal time occupancy on each channel . this also serves to minimize adjacent channel interference variation during reception of the packet on any given channel — primary or secondary . as a step towards achieving this goal , an aspect of the present embodiment calls for emoca nodes to use the maximum of the cp_length field as estimated across the primary and secondary channels and conveyed by the type - 3 probe exchange sequence . this results in both primary and secondary channels having the same ofdm - symbol length . a further aspect calls for both primary and secondary channels to use the same preamble - type for data transmissions as determined as part of the probe transmissions on the primary and secondary channels . as per a still further aspect , non - data transmissions ( such as probes ) that are transmitted on both primary as well as secondary channels use a set of parameters on both channels that result in equal transmission lengths . in order to realize high - data rates using emoca , data - packets are split across primary and secondary channels so as to result in an equal number of ofdm symbols ( and consequently an equal duration of transmission ). as an example , consider a data - frame of m - bytes . in a mode of operation , an emoca node may utilize an iterative method as described in the following to split the data - frame into an mp byte fragment for transmission on the primary - channel and an ms byte fragment for transmission on the secondary - channel , as depicted in fig6 a . first , the minimum number of ofdm symbols to be transmitted nas is determined as in equation ( 2 ), based on the total number of bytes to be transmitted mt in equation ( 1 ): where , lh and lcrc respectively denote the moca header - length and the moca crc length in bytes ; nbasp and nbass respectively denote the number of bits per ofdm symbol that can be transmitted on the primary and secondary channels using the chosen modulation profile . second , the number of bytes , mp and ms , to be transmitted on the primary and secondary channels are determined in equation ( 9 ) and ( 10 ) below , based on the steps of first computing the number of rs - code blocks in the primary and secondary channels brsp and brss in equation ( 3 ) and ( 4 ); determining intermediate results nmaxp and nmaxs in equations ( 5 ) and ( 6 ); and determining the parameters of the last rs code word of both the primary and secondary channels respectively —( kp , np ) and ( ks , ns ) in equations ( 7 ) and ( 8 ). third , the inequality of equation ( 11 ) is evaluated based on the values of mp and ms determined in ( 9 ) and ( 10 ). if the inequality of ( 11 ) is determined to be true , the value of p which denotes the number of pad bytes to be appended to the secondary stream is computed as per ( 12 ). if the inequality ( 11 ) is determined to be false , the value of nas as computed in equation ( 2 ) of step 1 , above is incremented by 1 and steps 2 and 3 comprising equations ( 3 ) through ( 11 ), are recomputed . the original payload - frame of length m 610 a is then split into mp 620 a and ms 630 a byte fragments as depicted in fig6 a . the primary fragment 620 a is constituted of the primary channel moca header 621 a , the primary channel payload subframe 622 a and the moca crc 623 a . the secondary fragment 630 a is constituted of the secondary channel moca header 631 a , the secondary channel fragment 632 a , the moca crc 633 a and the pad - bytes 634 a as determined in ( 12 ). the above embodiment represents a means of partitioning the data that leads to the optimal ( minimum ) amount of transmission time on the channel . it would be apparent to one skilled in the art that the iterative nature of the method above could be obviated lending to a simpler computation to determine the primary and secondary fragments at the expense of utilizing a non - optimal transmission time . an emoca node may realize reliable transmission by several means . as per one embodiment of the present invention , the repetition of the packet on both primary and secondary channels is utilized . consider the transmission of a data frame of m - bytes . due to the likely difference between the number of bits per ofdm symbol ( nbas ) that can be transmitted on the primary and secondary channels — nbasp and nbass , it is required that the transmission with the larger nbas be padded to ensure that equal number of ofdm symbols are transmitted on both primary and secondary channels . the transmission parameters are determined as per the steps below : first , the number of ofdm symbols nas to be is determined based on the smallest value of nbas from the set spanning the primary and secondary channels { nbasp , nbass }, as per equation ( 17 ). l = 208 * floor ( mt / 192 )+ 0 if mt mod 192 = 0 + 40 if 0 ≦ mt mod 192 & lt ; 32 + 74 if 32 ≦ mt mod 192 & lt ; 64 + 140 if 64 ≦ mt mod 192 & lt ; 128 + 208 if mt mod 192 ≧ 128 ( 16 ) where , mt represents the number of bytes in the moca packet , l represents the number of fec encoded bytes to be transmitted . second , the number of pad - bytes to be transmitted on the other channel , pother ( having nbas , other ) is determined in equation ( 22 ): where brs , other represents the number of rs - code blocks ; and [ kother , nother ] represent the parameters of the last rs code - word . third the fragments to be transmitted on the primary and secondary channels are determined as shown in fig6 b . the fragment to be transmitted using nbas , smallest 620 b comprises of the moca header 621 b , packet of length m 622 b and moca crc 623 b . the fragment to be transmitted using nbas , other 630 b comprises of the moca header 631 b , the packet of length m 632 b , moca crc 633 b and pad of length p 634 b . as per another embodiment of the present invention , an emoca node may realize reliable transmission by means of packet - repetition in time and frequency , as depicted in fig6 c . the data payload of m - bytes 609 c is repeated n - times to form a repeated payload of size m = n * m - bytes 610 c . the repeated frame may be transmitted using the method employed for channel multiplexing ( steps encompassing ( 1 ) through ( 12 )), where the fragment transmitted on the primary - channel 620 c comprises of moca header 621 c , primary payload sub - frame 622 c and moca crc 623 c and the fragment transmitted on the secondary channel 630 c comprises of moca header 631 c , secondary payload sub - frame 632 c , moca crc 633 c and pad 634 c . it would be apparent that the method of packet repetition as per the present embodiment is practicable by an emoca node with only primary channel capability as may be expected of low - cost , low capability emoca implementation . fig6 illustrates the method by which the embodiments of fig6 a , 6 b and 6 c may be realized by an emoca transmitter . an emoca node attempting to transmit using a packet using channel multiplexing invokes process 601 . as per the embodiments of the present invention , it first determines the number of ofdm symbols required as per step 605 . in step 606 , it determines mp and ms . based on the evaluation of the inequality in 607 , the transmitter adopts route 611 if it is determined a subsequent iteration is needed or route 621 if no further iteration is needed . as per route 611 , the transmitter increments the number of ofdm symbols determined in 605 in step 612 and re - evaluates step 606 in an attempt to satisfy the condition in 607 . as per route 621 , the transmitter determines the number of pad - bytes in 622 and splits the payload into primary and secondary channel fragments as in 623 . as per the methods embodied , a transmitter transmitting using the method of frequency - domain repetition as is illustrated in fig6 b , invokes process 602 . it determines the channel with the lower nbas 630 and uses this to compute the number of ofdm symbols 605 and the number of pad - bytes 622 based on which it generates the primary and secondary channel fragments in 623 . as per the methods embodied , a transmitter transmitting using the method of packet repetition as illustrated in fig6 c invokes process 603 . it creates repeated frame in 640 and then follows the steps 605 and 606 . on satisfying the condition 607 , it follows route 621 and determines the pad bytes 622 and generates the primary and secondary channel fragments 623 . as per yet another aspect of this embodiment , an emoca node may realize extended range communications with another emoca node by making use of a modulation profile with a lower number of bits per ofdm symbol than determined during the modulation - profiling of the channel using type - 1 probe transmissions in [ 1 ]. the usage of a more - robust modulation profile may be signaled on a per - frame basis through the reservation request using the unused values of bit - field phy - profile [ 5 : 0 ] field in the request element as specified in [ 1 ]. expanding on the encoding specified in [ 1 ], an emoca node shall encode the phy - profile as follows . it is envisioned that the extended - range transmissions would be made to both to the primary as well as secondary channels , requiring that the extended - range communications mode be used between emoca nodes only . it would be apparent that the method of reduced constellation order transmission as per the present embodiment is practicable on an emoca node with only primary channel capability as would be expected of a low cost low capability emoca implementation . it is further envisioned that reduced constellation order transmission may be combined with any of the transmission schemes embodied in 600 . as is evident from the description above , emoca nodes may transmit using one of several schemes . central to realizing these benefits is signaling the receiver on how to decode the primary and secondary fragments in order to realize the benefits of the transmission scheme applied . the emoca_tx_scheme applied by the transmitter ( and consequently to be applied by the receiver ) may be indicated using the emoca mac header transmitted on the secondary channel . since the emoca mac header follows the format of the moca mac header specified in [ 1 ], this signaling may be done by employing some of the bits marked reserved or unused in the current moca header [ 1 ]. the emoca_tx_scheme may also be transmitted on the primary channel . an emoca receiver receiving a high - data rate emoca transmission determines the number of ofdm symbols to be received on the primary and secondary channels from the map - frame and appropriately configures the primary and secondary receivers for reception . based on the actual length of the primary and secondary fragments ( as determined from the moca mac header while receiving the fragments ), the emoca - node determines the length of the pad as well as the fec - coding as per the methods of [ 1 ]. on completing the reception of both the primary and secondary fragments , the emoca - node combines the packet as per the flowchart of fig7 . the emoca receiver implementing the methods of 700 interprets the emoca_tx_scheme field from the received transmission in step 701 . if the emoca_tx_scheme is determined to be ‘ channel - multiplexing ’, process 702 is invoked whereby the moca - crcs on the primary and secondary channels — 623 a and 633 a being determined as valid in step 710 , the primary and secondary channel payload subframes 622 a and 623 a are combined in 711 to reconstitute the payload 610 a . likewise , on determining the emoca_tx_scheme field from a received transmission to be ‘ frequency repetition ’, the emoca receiver invokes process 703 . the moca crcs on the primary and secondary channels — 623 b and 633 b are evaluated and if any of them are determined valid in step 720 , the corresponding payload 622 b or 632 b is returned . likewise , on determining the emoca_tx_scheme field from a received transmission to be ‘ packet repetition by a factor of n ’, the emoca receiver invokes the process of 704 . the moca crcs 623 c and 633 c are ignored and the receiver combines the primary and secondary payload sub - frames 622 c and 632 c in step 730 , using a ‘ majority decision over n - rule ’ to determine the bits of the transmitted payload 609 c as per step 731 . fig8 represents an exemplary implementation of an emoca - node 800 that is capable of bridging emoca transmissions received over the coax cable - plant 860 to an application processor 850 over means of an interface 849 . like in [ 1 ], emoca nodes where the application processor 850 exposes a generic network interface 851 such as ethernet , pcie , usb , wlan or any other network interface for the purpose of bridging data from said interface 851 over the coax cable plant 860 , are called ‘ intermediate devices ’. also , like in [ 1 ], emoca nodes where the application processor 850 serves as a source and / or sink for data transmitted / received over the coax - cable plant 860 are called ‘ terminal - nodes ’. the emoca - node 800 comprises of a mac - processor 801 connected to memory 801 a , a primary - phy - processor 802 and a secondary - phy - processor 803 for operation on the primary and secondary channels respectively . 802 and 803 are connected to their respective front - ends — 804 and 805 which interface to the coaxial - cable - plant 860 over a single - coaxial cable 869 through means of a diplexer 806 . in keeping with the requirements of emoca for synchronous transmission across both channels , all components of the emoca - node 800 derive their clocks from a common clock source 807 . further , 802 and 803 are connected to 801 over interfaces 802 a and 803 a that are capable of independent parallel operation scheduled and controlled by 801 . in order to transmit a packet using emoca , the mac - processor 801 is responsible for performing the steps of : ( 1 ) receiving the data to be transmitted by the application - processor 850 ; ( 2 ) buffering it in memory 801 a ; ( 3 ) partitioning it into the primary and secondary streams as may be performed by the method embodied in 600 ; ( 4 ) generating a rr - frame and transmitting it to the nc ; ( 5 ) interpreting the map - frame from the nc and scheduling the synchronous transmissions of the primary and secondary streams through the phy - processors 802 and 803 at the transmission - time specified in the received map - frame . in order to transmit a packet using emoca , the phy - processors 802 and 803 are responsible for receiving their respective streams from the mac - processor 801 , performing the steps of fec - encoding , ofdm modulation ( using their respective phy - profiles ) and transmitting the output signals over interfaces 804 a and 805 a to the front - ends 804 and 805 which convert the digital bit - stream from the phy - processors to their respective rf - channel and feed their output to the diplexer which combines the primary and secondary rf - signals onto a single coax cable in order to receive a packet using emoca , the mac processor is responsible for performing the steps of : ( 1 ) computing the receive parameters of the primary and secondary channels based on the duration information contained in the map - frame ; ( 2 ) scheduling the phy - processors 802 and 803 to enable reception of the primary and secondary - streams using the computed parameters at the receive - time specified by the map - frame ; ( 3 ) receive the primary and secondary - streams from 802 and 803 , respectively and storing it in 801 a ; ( 4 ) receiving status information associated with the packet reception from 802 and 803 ; ( 5 ) combining the primary and secondary streams received from 802 and 803 , as may be performed by the method embodied in 700 ; ( 6 ) transmitting the combined packet to the application processor 850 . in order to receive a packet using emoca , the phy - processors 802 and 803 are responsible for enabling the front - ends for reception , receiving the down - converted primary and secondary streams from 804 and 805 respectively , demodulating and decoding them based on their respective phy - profiles and parameters and transmitting them to 801 over interfaces 802 a and 803 a , respectively . additionally 801 may use information obtained from 802 , 803 , 804 and 805 during transmission and reception to compute link statistics such as signal - quality , channel quality , power - level etc . as would be apparent to one skilled in the art . the information computed by 801 may also be used for instance to generate transmit - power control information which is fed - back to improve link - performance , among other applications as would be apparent to one skilled in the art . in order to facilitate the objective of transmission and reception using emoca , the phy - processors 802 and 803 are further responsible for generating probes and probe reports in accordance with the teachings embodied above . based on the embodiment of the apparatus for an emoca node described above , it would be apparent to one skilled in the art that the functional units described above may be implemented as dedicated hardware or software running on an embedded processor . moreover several realizations may exist with the functions of the mac - processor implemented on a dedicated network processor or being distributed among several embedded processors . further , depending on the level of integration , the emoca node described above may be implemented as one or as several integrated - circuits . it is understood that all such variations of an emoca node fall within the purview of the present invention . in order to facilitate the ease of deployment of emoca technology , emoca was developed as being fully backwards with legacy moca technology enabling both mixed as well as green - field networks . further , to keep the development costs low , emoca nodes may be constructed using components used for legacy moca - nodes as discussed in the ensuing embodiment . fig9 below describes an exemplary architecture of a legacy moca device 900 which is used as a building block of an emoca node as per an aspect of this embodiment . 900 comprises of a processor subsystem 910 , a host - interface subsystem 920 , a moca subsystem 930 and a clock subsystem 940 . the processor sub - system 910 comprises of a processor 911 , memory 912 as well as common - peripheral devices such as an interrupt - controller 913 , timer - unit 914 , boot - rom 915 , configuration register bank 916 and flash - interface 917 . the host - interface sub - system contains both an ethernet - mac 921 and an ethernet - phy 922 interface , allowing among other product configurations —( 1 ) the device 900 to be configured as a standalone ethernet - bridge by connecting 921 to an external ethernet - physical - layer 991 ; or ( 2 ) in an embedded application where 900 connects to an application device 992 over 922 . 921 and 922 also contain their respective smi - interfaces 921 a — an smi master , and 922 a — an smi slave . the moca sub - system 930 comprises of a moca mac hardware accelerator 931 which connects to a moca baseband phy processor 932 which in turn drives an analog - front - end 933 and an rf - front - end 934 which connects to the coax - cable plant via 995 . 930 also contains the system - time clock 935 which is updated periodically by the time - stamp from an ncs transmission and maintains the system - time at the moca node . the clock and reset subsystem 940 contains a pll 941 which generates a clock based on an external crystal oscillator 994 , from which are derived all the clocks required by the modules of 900 . the smi slave interface 922 a contains a set of 32 registers , each 16 bits - wide , as specified in the ieee 802 . 3 specification ( identified herein as [ 3 ]). of these , 16 - registers are defined in [ 3 ] while the other 16 - registers are left as ‘ vendor - specific ’. one of the vendor - specific registers is called the moca - system - time register and is mapped directly to the moca - system - timer 935 , allowing for a write to that register to reflect as an update to the time maintained by 935 . yet another vendor specific register — pll status register reflects the status of the pll 941 — locked or un - locked . when the system is powered up , the clock generator 941 supplies the clock from the external oscillator 994 to the processor which starts executing code contained in the boot - rom 915 . it determines the ‘ product - configuration ’ from the configuration register 916 which latches its value from an external interface such as a pin - strap 996 at startup . the processor programs the clock generator 942 to enable the appropriate peripheral clocks at their respective frequencies depending on product configuration . for example , while the moca phy - clock is determined by [ 1 ] and is constant , some product configurations may require higher processing power thus requiring the processor to be correspondingly clocked at a higher frequency than others . on acquiring a pll - lock from 941 , the processor configures 942 to switch the system to the higher frequency pll - clock and initiates the downloading of firmware into memory 912 leading to system boot - up . as would be apparent , to one skilled in the art , several options may be used for boot - up and these may be determined based on product configuration . based on the example of 900 , two possible boot scenarios are : ( 1 ) boot over ethernet — exploiting the download of code over one of the host - interfaces in 920 ; or ( 2 ) boot over flash using 917 to access code stored in external flash - memory 993 . in steady - state , the processor 911 coordinates the transmission and reception of packets over the various interfaces — ethernet - mac 921 , ethernet - phy 922 and moca / coax 930 through the use of data - structures known as descriptor - queues that are setup at designated areas in memory 912 . there is one descriptor - queue corresponding to each interface that is capable of operation in parallel with another — for example the ethernet phy or mac interfaces — 921 , 922 would support two descriptor queues each , one for transmit and one for receive ; while the moca mac hardware accelerator 931 would support a single descriptor queue since the moca interface is half - duplex in nature . additionally , all packets are stored in memory 912 . each frame that is received from any interface 921 , 922 or 930 has an associated descriptor in the descriptor queue containing the following information : rxpacketdescriptor := { packet location in memory , packet - length , parameters to be used during reception , status of reception } depending on the interface , it is likely that some of these fields are required prior to reception ( eg : parameters to be used during reception ) and some are determined after reception ( eg : status during reception ), resulting in an update to the descriptor . likewise each frame that is transmitted from any interface 921 , 922 or 930 is described by an associated descriptor in the descriptor queue containing the following information : txpacketdescriptor := { packet location in memory , packet length , parameters to be used during transmission , status of transmission } depending on the interface , it is likely that some of the fields of the descriptor are required prior to transmission ( eg : packet location in memory , packet - length and parameters to be used during transmission ) and some determined after transmission ( eg : transmission status ). in order to bridge a packet from the host - interface to the coax - interface , among other protocol functions described in [ 1 ] and [ 2 ], the firmware running on 900 performs the steps of : ( 1 ) creating a descriptor for the host - interface 921 and / or 922 to receive a packet ; ( 2 ) generating an rr and its associated descriptor in 912 for the packet received in step ( 1 ); ( 3 ) processing the map - frame received by 930 in response to the transmitted rr - frame to determine when to transmit the packet received in ( 1 ); ( 4 ) creating a descriptor for 930 to transmit the packet received in step ( 1 ) at time determined from the map - frame in step ( 3 ). likewise , in order to bridge a packet from the coax - interface to the host - interface , among other protocol functions described in [ 1 ] and [ 2 ], the firmware running on 900 performs the steps of : ( 1 ) creating a descriptor to facilitate 930 to receive a moca - frame using the parameters and time determined from the previously received map - frame ; ( 2 ) on reception of the packet by 930 into 912 in step ( 1 ), creating a descriptor to transmit it on the appropriate host - interface in 920 . fig1 embodies a realization of an emoca - node 1000 capable of using one primary and one secondary channel . the emoca node is constituted of two instances of a moca - device as embodied in 900 — primary 1001 a and secondary 1001 b . both 1001 a and 1001 b are connected to a common oscillator 1092 as shown in the figure . in a deployment scenario where the emoca node boots from flash memory , the flash - interface 1014 a connects to a flash device 1093 . internally , the ethernet - mac interface 1013 a of 1001 a connects to the ethernet phy interface 1011 b of 1001 b . also , the smi - interface 1012 a of the ethernet mac interface 1013 a in device 1001 a connects to the smi - interface 1010 b of the ethernet - phy interface 1011 b of 1001 b . the configuration registers — 1018 a and 1018 b derive their values from external pin - straps 1091 a and 1091 b , respectively . the primary and secondary rf - connections 1019 a and 1019 b connect to a diplexer 1094 which interfaces to the coax cable plant over connector 1095 . the ethernet phy - interface 1011 a and the smi - interface 1010 a of 1001 a may be connected to an application processor 1090 which interfaces to 1000 using an ethernet mac interface . when the emoca node 1000 powers - up , both 1001 a and 1001 b receive a common reference clock from 1092 . as described in the context of 900 , the clock generators 1016 a and 1016 b supply the reference clock to the processor in 1001 a and 1001 b , which execute their respective boot - roms . the processor 1030 a determines 1001 a &# 39 ; s ‘ product - configuration ’ to be : productconfigurationinformation ~ 1001a := { emoca device , primary - channel with one secondary - channel , boot - method processor frequency configuration } from the configuration register 1018 a that latches the pin - strap value 1091 a . likewise , the processor 1030 b determines 1001 b &# 39 ; s configuration to be the configuration register set information depicted above is meant to describe the minimum amount of information required for emoca operation . it is understood that in actuality the configuration registers 1018 a and 1018 b may contain additional fields . it is further understood that some of the information contained in the processor - configuration description above may be implicit from other parameters — for instance the processor frequency configuration may be determined a - priori for both primary and secondary devices and encoded as part of the boot - rom , thus not requiring this information to be part of the configuration registers 1018 a and 1018 b . like wise , 1001 b when configured as a secondary channel device , may be constrained to boot from the primary device 1001 a . the processor 1030 a executing code in its boot - rom , on detecting its pll 1016 a as locked , configures its clock generator 1017 a to enable the clocks to the appropriate modules at their appropriate frequencies based on the product configuration information in 1018 a . correspondingly , 1030 b on detecting 1016 b as locked configures 1017 b to enable the appropriate modules at their appropriate frequencies based on the product configuration information in 1018 b . based on the setup of 1000 , 1001 b can disable power to 1013 b , 1012 b and 1014 b thereby resulting in power efficient operation . thus , individual modules of the component moca - devices 900 ( referred as 1001 a and 1001 b ) in the emoca node 1000 may be gated or powered - down based on product configuration , thereby resulting in power - efficient operation of the emoca - node . further , as will become apparent through subsequent description of the present embodiment , the firmware - load on the processor of 1030 a and 1030 b may be different . it is a further aspect of this embodiment that depending on the product configuration in 1018 a and 1018 b , the processor - subsystems of 1001 a and 1001 b are clocked differently resulting in power - efficient operation of the emoca device . as stated in a previous embodiment of the present invention , key to realizing an emoca device is the synchronization of the transmissions from the primary and secondary channels . central to this is the synchronization of the system - timers 1015 a and 1015 b as maintained in 1001 a and 1001 b . while plls 1016 a and 1016 b are driven by the same reference clock 1092 resulting in their having a common frequency once locked , the difference in their lock - times and the corresponding ‘ early arrival ’ of the clock from one of the clock generators 1017 a or 1017 b to the moca system time counter 1015 a or 1015 b would result in an offset in the system - times as maintained and used by the primary and secondary channels . to overcome this problem , an aspect of this embodiment calls for the processor 1030 a on determining its pll 1016 a has locked , to determine that the pll 1016 b of 1001 b has locked by reading the status in the pll status register maintained in 1010 b using its smi - master interface 1012 a . on determining both plls 1016 a and 1016 b as locked , the processor of 1030 a writes a synchronization command over its smi - master interface 1012 a to the moca system time register 1015 b as exposed through the smi - slave interface 1010 b . the synchronization command - word accounts for the latency in accessing 1015 b over 1012 a and 1010 b such that on conclusion of the synchronization process , both 1015 a and 1015 b reflect the same system - time . the boot - rom of 1001 a then initiates the downloading of firmware prior to complete the boot - up process . as described previously in the context of 900 , the emoca device may boot - up using a variety of options . as per one product configuration , the primary - device 1001 a could be connected to an external flash - memory device 1093 , containing the firmware image . 1001 a may initiate a code download to memory 1031 a and then transfer the image over , for instance , the ethernet interface 1013 a to 1001 b through 1011 b . as both primary and secondary channels have different functions to perform , it is understood that the firmware image executed on 1001 a and 1001 b may be different . alternately , instead of using flash - memory 1093 , the emoca node 1000 may obtain its firmware image from an application processor 1090 using interface 1011 a . internally code may be transferred to 1001 b , as described above . as per an aspect of this embodiment , an emoca - node 1000 , on receiving a packet to be transmitted over the emoca network from 1090 stores the packet in memory 1031 a . 1030 a then executes the method of embodied in 600 to determine the length of the primary and secondary fragments . 1030 a then generates a rr - frame corresponding to the duration of the emoca transmission and an associated descriptor for transmitting the rr on the coax interface . 1030 a also generates descriptor for transmitting the following information to 1001 b . secondaryfragmenttxinformation := { frame_subtype frame_type destination phy_profile request_id probe_index ( if transmission is a probe ) secondary - fragment including any associated pad as determined by the method of 600 ( if data / control frame ) } 1001 b receives the information transmitted above and stores it in 1031 b . on receiving the map - frame from the nc , the processor 1030 a immediately schedules its transmission to 1001 b over interface 1013 a . both 1030 a and 1030 b process the map - frame independently and create descriptors for the transmission of the primary and secondary fragments at the time stipulated for the corresponding frame in the map - frame . by virtue of the fact that both 1015 a and 1015 b are synchronized as previously described , transmissions on 1019 a and 1019 b occur simultaneously , resulting in an emoca multi - channel transmission on the coax cable 1095 . as discussed above , on receiving a map - frame from the nc , the processor 1030 a immediately schedules its transmission to 1001 b over interface 1013 a . in the case of a packet to be received from another emoca node both primary and secondary channel devices 1001 a and 1001 b schedule reception of their corresponding packet fragments using the parameters contained in the map - frame and the method described in [ 1 ]. upon completing reception of an emoca transmission the secondary - device 1001 b schedules transmission of the following information to 1001 a over the interface 1011 b : secondaryfragmentrxinformation := { src from map - frame , request id from map - frame , secondary - fragment stripped of any pad - bits as received over 1019b secondary - fragment reception status emoca_tx_scheme } the primary device 1001 a receives the packet over 1013 a and stores it in 1031 a . the processor 1030 a then recombines the packet as per the steps embodied by the method of 700 . 1030 a then schedules the transmission of the packet to the application 1090 over its interface 1011 a . in the event of an error while receiving a secondary fragment , 1001 b may substitute the secondary - fragment field in the secondaryfragmentrxinformation above with a null , so as to eliminate wastage of resources in transferring an errored frame from 1001 b to 1001 a . as would be apparent to one skilled in the art , the moca system timers 1015 a and 1015 b , though synchronized with one another may drift with respect to the ncs system - timer over time . in order to maintain synchronism , the emoca device 1000 periodically updates the system - time maintained by the primary and secondary devices 1001 a and 1001 b in 1015 a and 1015 b , as per the following steps : ( 1 ) on receiving a transmission from the nc , the moca subsystem of 1001 a logs a time - stamp of the packet received from the timer 1015 a ; ( 2 ) based on this time - stamp , 1030 a computes the offset of 1015 a with respect to the ncs transmission - time of the packet ( as contained in the packet header ); ( 3 ) 1030 a schedules an update to 1015 a and 1015 b at a time when there is no transmit / receive activity as scheduled by the nc through the map - frame ; ( 4 ) the schedule ( specified below ) is communicated to 1001 b via the interface 1013 a ; ( 5 ) both 1015 a and 1015 b are updated simultaneously with the offset , realigning them to the ncs system - time . while certain embodiments of the inventions have been described above , it will be understood that the embodiments described are by way of example only . accordingly , the inventions should not be limited based on the described embodiments .