Field of the invention The invention relates to a method and a system for delivering secured multicast services such as video to multiple clients in a passive optical network (PON) by multicasting, where the services are delivered from a central unit (Optical Line Termination) through the passive optical network to Optical Network Terminals or Optical Network Units respectively associated with the clients (customers).

Background of the invention

The well known and widely used Internet Group Management Protocol (IGMP) is used by IP hosts to report their multicast group memberships to any immediately neighboring multicast routers. For example, in the IGMP version 2 (RFC 2236), messages are encapsulated in IP datagrams, comprising at least the type of message and a group address. The group address identifies a multicast channel and is to be understood as the IP multicast group address of the group being reported or left. The IGMP version 2 protocol includes mainly three types of messages in the host-router interaction; 1) a membership query message sent from the router to hosts, 2) a membership report message such as an IGMP "join group" message sent from a host to the router, and 3) an IGMP "leave group" message sent from a host to the router.

The IGMP protocol enables every one of the hosts to request delivery of any multicast channel available from the IGMP router by sending a "join group" message to the router and indicating the channel. The IGMP router registers the host as a member of the IP group and then the host is provided with the channel that has been ordered. It should be noted that in addition to this newly ordered channel, the subscriber unit may receive all the channels ordered by other members of the same IGMP network. IGMP protocol is a straightforward way of serving multiple subscribers within a passive optical network (PON) that provides multicast services. The customers of PON are usually associated with so-called Optical Network Units ONUs (or Optical Network Terminations ONTs). The OLT (Optical Line Termination) is usually

situated in a central office. In the rest of the document, ONT should be understood as either ONT or ONU.

In the case where the OLT comprises an IGMP router, the OLT is in charge of collecting part/all of the IGMP requests from the customers joining a group (as in the conventional IGMP protocol), to figure up which multicast channels are to be delivered to the ONTs. For example, a multicast channel can be ordered by a customer via a remote control unit associated with a Set Top Box (STB) of the customer's TV receiver. The STB cooperates with a corresponding ONT. Upon receiving an IGMP request from one of the customers, OLT transmits the ordered multicast channel downstream, via the PON interface. Each multicast channel is sent by OLT to all members of the IGMP network. The IGMP network may include from 1 to n hosts. Usually n doesn't exceed the maximum number of ONTs where each ONT includes only one IGMP host.

At the PON physical layer, all the information is shared between all ONTs. This fact is due to the physical characteristics of the PON. In order to prevent end- customers to access information not dedicated to them, unicast traffic is usually churned (scrambled). But such function is not provided at the PON level for multicast streams. In other words, if a customer served by a specific ONT orders a multicast channel - the ordered channel can be potentially received by all the ONTs of the same PON even if some of these customers are not entitled to see the channel.

One way to prevent customers in a PON environment to access information that he is not entitled to receive, is to use a unicast churning function. This function, where a key is shared between the OLT and the ONT, can not be used for multicast services where the encryption should be applied per channel or per group of channels. A known multicast encryption key exchange method disclosed in a publication US20020150097 comprises selecting/generating a multicast encryption key from among the churning keys belonging to the network devices, and periodically updating the key by delivering to the network devices the difference values between the updated multicast encryption key and the respective churning key of each network device. The process, for the ONT to get the churning key, requests an exchange of several messages between the OLT and ONT and vice-versa. It may therefore be impossible to deliver the encryption/churning information fast enough to the ONT of the customer that just requested a new channel in case the churning key in not know previously by the ONT.

Object and summary of the invention

It is therefore an object of the invention to provide a method and a system enabling a secure multicast transmission of multicast services in a PON (passive optical network).

The above object can be achieved by providing a method of multicast transmission in a PON communication system, using IGMP protocol and an IGMP router, to a group (plurality) of hosts each associated with an IGMP host to serve respective end customers of the PON communication system, the method comprises: - requesting (zapping) a multicast channel by a particular end customer, using

IGMP protocol, if the particular end customer is entitled to access said multicast channel,

- adding said customer to a multicast group including, upon adding said particular end customer, at least one of the end customers, - delivering said multicast channel, being churned, to the end customers belonging to said multicast group, and

- providing for said particular end customer access to said delivered churned multicast channel in response to said request.

Those skilled in the art understand that the number of members in the multicast group may be equal to or less than the number of hosts serving the respective end customers in said plurality.

The step of requesting the multicast channel is performed by using IGMP protocol in the PON (passive optical network).

The PON may be, for example, an ATM-based PON (APON, BPON, specific types of GPON) or an Ethernet-based PON (EPON).

The step of delivering the multicast channel is performed with the aid of the IGMP router. The IGMP router can be part of OLT (Optical Line termination) or can be located in the core network communicating with the OLT (the network "feeding" the OLT). The host comprises equipment serving an end customer and located at or in proximity to the customer's premises. The IGMP host can be located either in a Set Top Box (STB) situated at the end-customer's premises, a personal computer (PC), at the Optical Line Termination (ONT, can be also ONU), or both in the STB and ONT, in this case the ONT is an IGMP proxy.

Optical Line Termination OLT and Optical Network Termination ONT should be understood as defined in ITU-T Recommendations G.983.1 (ATM-PON) and ITU- T G.984.1 (Gigabit-capable Passive Optical Networks).

Most commonly, the multicast channels are video channels; each of the ONTs is connected to at least one TV Set Top Box (STB) or any other system capable of decoding video streams. When the corresponding end customer requests a channel, the mentioned IGMP message is initiated from the corresponding STB or PC via the

ONT.

In the preferred version of the above method, the step of requesting a channel (a zapping request) is performed by sending an IGMP message (request) from an IGMP host, serving said particular end customer and located at the customer premises, to an IGMP router located either at OLT or any other entity communicating directly or undirectly with the OLT, the request indicating said requested multicast channel to be delivered to the particular end-customer; and the step of providing the access to the particular end customer comprises sending a code key message from said OLT to the particular ONT in response to said

IGMP request, the code key message comprises churning information being information about churning key, for further dechurning said requested multicast channel.

The mentioned IGMP request format can be for example a "membership report" as described in the IGMP version 2 standard which is also called IGMP "join a group" message. Other versions of the IGMP standard are also relevant, for example the IGMP version 3 with its membership report message. The requested multicast channel is indicated in the IGMP request by the IP multicast address of the channel.

In case IGMP version 3 (described in RFC 3376) is used, the IGMP request may optionally comprise an additional information voluntary inserted at and sent from the ONT upstream to the OLT during the zapping request. The use of the additional information will be described as the description proceeds.

Any time when the word "multicast" or "unicast" is used, it should be understood that it relates to layer 2 (presented here as ATM or Ethernet), unless specified differently.

The churning function is described in the ITU-T G.983.1 Recommendation as a function usually being activated for point-to-point downstream connections. Churning provides a function of data scrambling and offers some basic level of protection for data confidentiality at the physical layer. The above-defined technology proposes a method for secured multicast in a

PON communication system, per each channel or group of channels (called a package). In other words, any multicast channel or group of multicast channels sent downstream through a PON communication system is secured so as to be accessible, at the current moment of time, only at the ONTs serving the end-customers entitled to receive the channel.

Each of the ordered multicast channels is churned for transmission by using a churning key (multicast churning key) specific for that channel or for a group of channels.

Dechurning of the data received via such a multicast channel is performed by data unscrambling at the ONT using the churning information that it received from the OLT in the frame of the code key message. Examples of the ways to use the churning information are described further below.

In the prior art method of US 2002/0150097, when multicast services are used, churning keys are collected by OLT from ONTs, one key is selected and then transmitted, using a safe transmission method, to the rest of the ONTs so that the

ONTs entitled to receive the information may dechurn it. This method suffers from many iterations, and therefore may delay the zapping process.

In the proposed method, a churning key is provided per channel or per package, thus to allow controlling entitlements at a channel or a package level. If a channel is not presently requested, the churning information is unknown to the ONT.

Therefore, when requesting a new channel, the ONT should receive the churning information as fast as possible so as not to increase the zapping time.

During zapping, the method proposes to transmit the churning information from the OLT to the ONT using several options depending mainly on the fact that the channel transporting the information is secured or not.

In the case where the protocol used to transmit the code key message is transported over a layer 2 unicast churned connection (an example - OMCI message) using a churning key dedicated to the ONT, the multicast churning key may be sent directly to the ONT without extra encryption of the key. In this specific case when the

churning key is directly inserted in the message sent to the ONT, the churning information is equal to the churning key.

Alternatively, the code key message can be sent through a multicast connection to all ONTs or through a unicast connection or any kind of path shared at the physical layer between several ONTs; in this case the message, the churning key should be encrypted, so as to enable decryption of the churning information only by the entitled particular ONT. In this case at least three possibilities are available.

The first one is to use one of the various encryption/decryption algorithms, for example a DES algorithm, a 3DES algorithm, an AES algorithm and RSA algorithm. The second possibility is to transport the churning information by using some information shared by both the ONT and OLT at a specific moment of time. This shared information may be the MAC address of the ONT, its IP address if it exists, a registration number or any other information or combination of information known at a specific moment by both the ONT and the OLT. As an answer to a zapping request, the OLT may use this shared information to inform the ONT about the selected churning key by transmitting to the ONT, for example, only the difference between the shared information and the churning key. This result will actually be the churning information. Operations more complex or simple than the subtraction may also be used to determine the churning information. For example, the churning information may be equal to the shared information, thus the shared information becomes the churning key.

The third possibility is for the ONT to send a random number to the OLT during the zapping request itself, so that the OLT can use this information instead of the 'shared information' described in the second possibility. Sending this random number is possible, for example, when using IGMP version 3 for the request and utilizing the Auxiliary Data part of the Group Record of the IGMP version 3 "membership report message".

On a new customer request, two cases should be distinguished when determining the churning key: 1. The newly requested multicast stream is already received by at least one other customer on the OLT PON interface (the multicast group comprises at least one member before the new customer joins it); 2. No customer is yet receiving the channel on the IGMP PON interface.

In the first case, the churning information should be determined using the churning key presently being used for the multicast channel churning. In the second case, the OLT should either randomly determine a churning key and then deduct the churning information from it, or use the shared information as the key itself. As it has been mentioned, the churning information is transported from the

OLT to the ONT using a message called the code key message. The method therefore comprises a step of receiving, by the particular end customer, the code key message with said information about a specific churning key used for churning the respective ordered multicast channel, and a step of dechurning thereof at the ONT. Preferably, the code key message is transmitted in the form of a PLOAM

(Physical Layer Operations Administration and Maintenance) -message of a specific type which will be described in the detailed description. The code key message can be as well transmitted, for example, via a management message, such as an OMCI (ONT Management and Control Interface) message, or by any other protocol/message type. The advantage of the PLOAM message is its real-time capabilities.

The multicast churning key can be periodically refreshed, for example said code key message can be periodically modified and resent to the relevant end customer(s) receiving the suitable multicast channel (members of the multicast group). Still, an additional level of security can be obtained by encrypting the churning information within the code key message.

For PON supporting ATM (APON, BPON and partly GPON), the code key message transporting the code key may also comprise information concerning VP/VC (virtual path and virtual connection indications) in which each of the requested channels can be received. When receiving the code key message including the VP/VC, the ONT may configure both VP and VC, as well as any specific filter to allow the specific channel into the ONT. For GPON, the code key message may comprise information about a relevant Port-ID (identifying a specific channel/port in which the multicast channel can be found). The ONT can be configured to a specific type/format of the multicast service, if declared in the code key message. Finally, using the churning information, the requested channel is dechurned into the ONT.

Information about the multicast channels respectively allowed for each particular end-customer can be stored as entitlement information. The entitlement

information relevant to each of the ONTs can be stored either at the OLT or within any other access control dedicated server interacting directly or indirectly with OLT.

Issuance of the code key message is preferably preceded by comparing the requested channel(s) with the entitlement information, and by checking, for example, the following four criteria:

- Is the subscriber (the end customer) entitled to receive any multicast content? Is the subscriber entitled to receive the specific multicast content he/she requested?

- Is the subscriber exceeding the maximum number of authorized simultaneous channels he/she is entitled to receive?

- Is the subscriber exceeding the maximum simultaneous multicast bandwidth (including the control channels bandwidth) he is entitled to receive?

Depending on implementation models, when ordering a new channel, each particular ONT may need to configure its access interface. Whenever the channel is allowed for the customer and bandwidth limitations of the ONT interface are complied with the service requested, the code key message ensures the particular entitled ONT to obtain information enabling it to control/adjust/configure its access to multicast channel(s) delivered by the PON. As mentioned, the information contained in the code key message may include not only the churning information; optionally it may comprise data about the service type transported by the requested channel, and/or the port-ID or the VP/VC on which the ordered channel may be found.

According to another aspect of the invention, the object of the invention can be achieved by providing a system for multicast transmission in a PON communication system, capable of implementing the above-described method. In particular, there are proposed, separately and in combination, an Optical

Line Termination (OLT) and An Optical Network Termination (ONT) for the PON.

The inventive Optical Line Termination (OLT) for a PON communication system is provided, capable of performing multicast transmission, using IGMP protocol and an IGMP router, to a plurality of Optical Network Terminations (ONTs) each associated with an IGMP host and serving respective end customers of the PON communication system, the OLT being capable of : .

- receiving an IGMP request for a multicast channel from a particular end customer via a particular ONT, and forwarding said IGMP request to the IGMP router; in case said particular end customer is entitled to access said multicast channel and is added to a multicast group by said IGMP router, the OLT being operative to

- deliver said multicast channel to the end customers belonging to said multicast group, while churning said multicast channel using a churning key, and

- allow, for said particular end customer, access to said delivered churned multicast channel in response to said IGMP request by sending a code key message to the particular ONT, wherein the code key message comprises churning information about the churning key, for dechurning said requested multicast channel at the particular ONT.

Preferably, the OLT is capable of producing said churning key using information transported in said IGMP request from said ONT. The OLT may be also operative to transmit indication of a service type or format of the requested multicast channel in said code key message to said particular ONT. The code key message, for example, can be a Physical Layer Operations Administration and Maintenance (PLOAM) message.

An inventive Optical Network Termination (ONT) is provided for serving, in association with IGMP host, an end customer in a PON communication system, the ONT being capable of :

- forwarding an IGMP request for a multicast channel from the end customer to an Optical Line Termination (OLT) being in communication with IGMP router,

- receiving the requested multicast channel from said OLT in a churned form, - receiving a code key message from the OLT, extracting from said message information about a churning key used for churning said channel, and obtaining said churning key;

- dechurning said multicast channel using the churning key.

The IGMP request can be an IGMP version 2 or 3 message of the type "membership report" indicating address of said requested multicast channel. When using the version 3 IGMP message, the ONT may voluntary insert additional information into the message, and if this additional information is used in the OLT for creating the churning key, this same additional information is further used in the ONT for obtaining the churning key from the churning information.

The ONT is preferably self-configurable in response to indication of service type or format of the requested multicast channel, whenever said indication is provided in the code key message.

Brief description of the drawings

The invention will further be described with reference to the following non-limiting drawings, in which:

Fig. 1 is a schematic view of a PON comprising an OLT and a number of ONTs illustrating the proposed method. Fig. 2 is an example of a schematic template of the IGMP message (request) with a requested channel and additional information indicated in the message. Fig. 3 is an example of a schematic template of the "code key" message according to the invention. Fig. 4 is a schematic table illustrating an example of entitlement information stored at OLT.

Fig. 5 is a schematic block diagram illustrating check up of entitlement information at OLT upon receiving an IGMP request from ONT.

Fig. 6 is a schematic block diagram illustrating ONT state machine after reception of the 'code key' message.

Detailed description of preferred embodiments

Fig. 1 illustrates an example of a Passive Optical Network (PON) 10 comprising an Optical Line Termination (OLT) 12 which communicates, for example, with a north- band positioned IP network (not shown), and connected via a passive optical splitter 14 and optical fibers to a plurality of hosts being Optical Network Terminations ONTl ... ONTn (generally marked 16). In this particular example, the OLT incorporates an IGMP router. The hosts (shown as ONT blocks) can be also ONUs. Fig. 1 illustrates how the proposed method can be implemented in the PON 10. Suppose an end-user, via an STB 17, orders a new multicast channel (Channell) from the OLT 12. To this end, ONTl receiving an IGMP message generated by STB 17, forwards this IGMP version 3 message (request) 18 to OLT 12 at the time tl. In this example, the request comprises indication of the Channel 1 and additional data (AD) selected by ONT and sent to OLT for encrypting the churning key. OLT receives the IGMP request and analyzes, whether the end-user served by the ONTl is entitled to

the requested channel. If yes, at t2 the OLT 12 transmits the Channel 1 (see the arrow marked 20) requested by the ONTl, as a churned multicast channel via the point-to- multipoint PON interface to all ONTs of the plurality of ONTs 16. Simultaneously (but possibly, beforehand or after), OLT 12 sends to ONTl a 'code key message' (CKM) 22. The code key message comprises the churning information calculated at the OLT based on the churning key it selected for use and on the data received from the ONT in the frame of the IGMP request 18. The code key message also comprises information for adjusting and/or configuring/reconfiguring the ONT PON interface according to that message and an optional VP/VC information (for APON, BPON, and some GPON networks) and optional service type information, so as to allow access to the delivered channel.

The code key message is preferably protected to allow using it only by the ONT which has ordered the corresponding channel. In this example, the code key message is transported by a PLOAM message. Alternatively, it can be sent via a multicast channel (common channel shared by all ONTs) or a unicast channel (dedicated to a specific ONT). In the case of unicast transmission, if an ATM connection is used, it should be churned using the classical unicast churning function specified in various PON standards, the code key message is thus protected from being intercepted by other end customers of the PON. If the code key message is transmitted via a multicast (layer 1 or 2) shared channel, an encryption algorithm should be used to encrypt at least the churning key (code key). PLOAM channel can be intercepted by all ONTs, so the churning information, if inserted in the PLOAM message, should preferably be encrypted. ^*

Actually, according to the PON point-to-multipoint principle, all the ONTs from the group 16 might receive the code key message 22. However, only the ONTl is capable of extracting the relevant key from the code key message; therefore only ONTl is shown as receiving it.

It should be noted that the code key message is transmitted via a control channel or a management channel, in contrast to the multicast channels transmitted as data traffic.

Upon receiving the code key message 22, ONTl extracts the churning information there-from and obtains the code key for de-chuming the received multicast channel.

Fig. 2 illustrates an exemplary template of an IGMP request message 30, for example a message similar to the IGMP Version 3 of the type "membership report" The format of such a message is proposed, for example, in RFC3376. Alternatively, it can be a similar message of the IGMP version 2, though it does not have some options proposed by version 3. The first portion of the IGMP packet format comprises the message type. In this particular case the type will be the "Membership report" message. The second portion is for a Checksum of the message. The portion relevant to the present invention comprises a number of fields "Group Record" 32, each of the fields 32 comprises a sub-field "Multicast Address" (marked 34) available for indicating address of a requested multicast channel, and a sub-field "Auxiliary data" (36). If a multicast channel is requested by the end customer served by ONTl, the address of the channel is inserted in one of the fields "Multicast Address". In this example of the invention, the IGMP request message 30 carrying the address of the requested channel in one of the sub-fields "Multicast Address" 34 also transports additional information (say, a random number F) inserted in the corresponding sub- field "Auxiliary Data" 36. The additional information is inserted in the message 40 at the ONTl requesting the channel, and is stored at the ONTl. This information can be inserted voluntarily and can be immediately used at the OLT for producing a so-called churning information from a churning key applied to the requested multicast channel. The churning information will be then transmitted from OLT to the ONTl in the frame of a code key message (see Fig. 3) for further decrypting it at the ONTl and dechurning the requested multicast channel. As can be seen from the illustrated example, more than one multicast channel can be ordered by the end customer simultaneously, and each of the channels can be accompanied by a specific number selected at the ONTl and inserted in the corresponding sub-field "auxiliary data" in the message 30.

Fig. 3 illustrates an exemplary template 40 of a code key message; in this example, it is a PLOAM message (described in ITU-T Recommendations G.983.x) which also serves for configuring a multicast connection in an ATM-based passive optical network (APON, BPON), and also GPON. The exemplary message comprises 12 octets (bytes), which carry the following information. The template comprises a number of sections schematically marked 41-47 and corresponding to specific octets. Section 41 indicates that the message is directed to one specific ONU and gives its

identification: the ONU-ID. Section 42 indicates the message ID (in this case, the proposed in the invention "code key message"). Section 43 further defines the message type by indicating whether it configures the multicast VP, or both the multicast VP and VC, or Port -ID. Section 44 points out the multicast VP connection. Section 45 specifies the multicast VC connection. For GPON communication systems, sections 44 and 45 comprise information about ports to be used at the ONU (Port-ID) instead of information concerning VP/VC connections. Section 46 defines the service type (or format) of the multicast stream transported by the VP/VC or the port-ID, which may require configuring of the ONT according to the multicast service type. Section 47 comprises the churning information concerning the churning key of the requested multicast channel, for obtaining the churning key at the ONTl .

Fig. 4 illustrates an example of arranging the so-called entitlement information for a group of end customers served by particular ONTs, in a table form 50. It should be noted that the entitlement information can be presented in a different way (say, in a form of tree), and can be stored in an access control server that can be part of either OLT, or other component of the network feeding the OLT. In this case, the relevant entitlement information can be requested from OLT, using a communication protocol. Though in the table 50 each of the customers is associated with a single ONT, it should be noted that an ONT (usually ONU) may serve several customers.

For each of the ONTs, the table presents information as to whether the customer served by the ONT is entitled to multicast services. The table specifies which specific channels are entitled channels for the customer; these channels are given as a list of channel numbers. Further, the table presents limitations per customer for a number of simultaneously accessible multicast channels (NOC) and for the maximal allowed bandwidth of simultaneously accessible channels (MaxBW).

Whenever a particular ONT requests a multicast channel, the request is analyzed in the access control server based on the entitlement information presented in table 50.

Fig. 5 illustrates an example of a flow chart explaining some possible versions of the proposed method, including analysis of the customers' requests at OLT and reactions to the requests.

Upon receiving at OLT a request from ONTl say, in the form of an IGMP message "membership report" indicating the group address of Channel 1, (Block 60), the OLT

analyses the entitlement information with respect to the ONTl end customer information. If the customer is not entitled to any multicast transmission and/or if its not entitled to the specified channel 1, the OLT will reject the request (blocks 62, 64). If the mentioned conditions are satisfied, the OLT further checks whether the present status of the simultaneously transmitted channels and simultaneously used bandwidth allows increasing them for the ordered one additional channel (blocks 66, 68). If the answer is no for any of the latest questions the request is rejected . If the answer is yes for all the previous questions, the requested churned Channel 1 is sent from OLT downstream to the PON interface (block 72). Then (or even earlier) the code key message is sent from OLT to the ONTl (block 74) in order to allow configuring or reconfiguring its interface to access the delivered channel and unscramble it. In this example, the code key message comprises an encrypted churning key in the form of churning information which can be obtained by applying shared information to a churning key selected or produced by OLT. The random number (F) inserted in the sub-field "Auxiliary Data" 36 of the IGMP request ¹ 30 and associated with the requested multicast channel can play the part of the shared information.

Fig. 6 illustrates the decryption process at the ONT via which a multicast channel was ordered. The exemplary flow chart shown in Fig. 6 comprises Box 80 for receiving a code key message (here - a PLOAM message 40) at ONTl. Box 82 of the flow chart is responsible for reconfiguring the ONTl in response to the code key message, namely for opening VP/VC filters at the ONTl interface in case the PON is APON or BPON. For some implementations of GPON, box 82 will detect information about a specified port ID of ONTl and activate it. If the multicast service type indicated at the field 46 of the message 40 necessitates adaptation of the ONTl it is also provided in the frame of box 82.

Box 84 indicates operations of obtaining the churning key from the PLOAM message with preliminary decrypting the churning information transmitted in the field 47 of the message 40 using the shared information known both to the OLT and ONTl. In this example, the shared information is the random number F that has been inserted in the field 36 of the IGMP request 30. However, the shared information must not be always transmitted from the ONT to OLT; it can be formed by or combined from different kinds of data which just must be known to both the OLT and ONT at the

specific time. Box 86 indicates an operation of de-churning (descrambling) of the multicast channel with the aid of the churning key obtained at box 84.

In view of the above-described principles and examples, the above-defined technology of controlled access to multicast information in a PON communication system differs from other known technologies in that it proposes a) the multicast churning/encrypting and b) _, a new message (the code key message) to be issued from

OLT to a particular host, and using these measures in order to grant to the corresponding end customer (and only to that customer) access to the presently requested channel(s).

The access control can be performed at several layers. The first layer of the access control is performed by encoding and further decoding the multicast data itself (with the aid of multicast churning and dechurning). A further layer of the access control can be made by protecting a code key message which carries a key for decoding the ordered channel at the dedicated host; the protection at this layer can be performed by churning the message . Yet an additional security layer can be applied by encrypting the very key information inserted in the code key message.

At the host interface (ONT), the security is implemented by configuring/reconfiguring input filters of the interface in response to the received code key message, dechurning the message and/or decrypting the churning key, and dechuming (descrambling) the received multicast channel.

While the present invention has been described with reference to a limited number of examples, it should be appreciated that other versions and embodiments can be proposed and be considered part of the invention whenever covered by the claims which follow.