## 3 Channel Proximity Discovery
### The System of Channel Proximity Discovery  
As described in the above section, each router maintains the per-flow status of the multicast groups it forwards. The proposed system facilitates authorized end-users to exploit this information in multicast routers to discover the proximate in-progress channels. From this information, other users can subscribe to any of these channels without any additional traffic to the upstream network. We propose a user-initiated mechanism to use this in-network capability of multicast networks to allow users to discover the proximity of these channels without explicit notifications from other users.  
The proposed user-initiated process of proximity discovery in IP multicast is shown in Figure 3 that can be broadly characterized as a pull-based approach. A user can periodically query nearby multicast routers (step 1) and join with any interesting proximate group. However, the routers maintain the multicast addresses in numerical format, where these addresses need to be resolved to user understandable names (_i.e._, using a network name resolution service similar to DNS for WWW) before a user can decide which channel they would like to subscribe. For this purpose, the user sends the queried addresses to a proposed Proximity Name Service (PNS) server as in step 2. Multicast application providers, who would opt to participate in this new service paradigm, are expected to register their TV channels with the PNS. Resolved addresses (_i.e._, named TV channels) can be announced to the user by means of Electronic Program Guide (EPG) or inserted advertisements. Users can subscribe to any proximate group that interests them (step 3).  
Figure 2: Routing in IP multicast.  
One PNS can be placed in a large geographical area as proximate channel announcements only target a requested user. Control traffic overhead can further be minimised allowing only qualified members to query and only registered channels to be responded at a proximity query-able router. The system can be implemented in a hierarchy as well. At the leaf router a user may find lesser number of in-progress sessions but these may be closest to the user. However, if a user can query other routers (higher up in the tree), they could potentially join more proximate sessions, though these would be found further into the network.  
As shown in Figure 2, user A has joined with channel-1 first. Therefore the multicast address of channel-1 should be in the forwarding table of router X. Then the user B's STB (through periodic queries) will read this address and send to the PNS to resolve it. The resolved information will be available to the user B. Then user B can join with channel-1 without any extra traffic introduced to the network before router X. If user B's STB is allowed to query router Y, it will see both channel-1 and channel-2 are close by. However, changing to channel-2 introduces more traffic to the network (distant than channel-1).  
An end-user querying the multicast table of a router which forwards data to many users, brings scalability, privacy and security issues. We propose to re-allocate a set of Source Specific Multicast (SSM) addresses from the IPv4 range 232.0.1.0 to 232.255.255.255 (In IPv6, this range is from FF3X::8000:0 to FF3X::FFFF:FFFF) [13], which has been allocated by IANA to dynamically use, when supporting proximity discovery for managed multicast applications. Then, a multicast router will respond with the ongoing multicast sessions that belong only to the assigned range. If an application provider decides to preserve the privacy of the users, like adult TV channels, they can avoid using addresses from the reserved range. This also reduces the size of the list of multicast addresses a router should respond to a user.  
Figure 3: Query steps of the proximity discovery system.