Introduction
The success of wireless and mobile communications in the 21st century has resulted in a large variety of wireless technologies, including second and third-generation cellular, satellite, Wi-Fi, and Bluetooth. Heterogeneous wireless networks combine various wireless networks to provide universal wireless access. Leading wireless companies in some countries operate networks with multiple technologies, such as T-Mobile in the United States, British Telecom in the United Kingdom, Orange Telecom in France, NTT DoCoMo in Japan, and Chunghwa Telecom in Taiwan.
The number of companies offering seamless services in networks with multiple wireless technologies is expected to increase due to the proposed standards by the Third-Generation Partnership Project (3GPP) and Unlicensed Mobile Access (UMA). In heterogeneous wireless networks, users are typically covered by multiple cells to prevent connection drops and service disruptions. Furthermore, mobile terminals in these networks are increasingly likely to have multiple wireless technologies.
Therefore, heterogeneous wireless networks provide mobile hosts with many choices for accessing the internet, including different cells and wireless technologies.
Purpose:
This project deals with resource allocations in heterogeneous multicast networks using a bandwidth-efficient multicast mechanism. Our mechanism allows more mobile hosts to cluster together, leading to the use of fewer cells and saving scarce wireless bandwidth. Additionally, the paths in the multicast tree connecting to selected cells share more common links, which saves wireline bandwidth.
Our mechanism supports dynamic group membership and offers mobility for group members. We formulate the selection of the cell and wireless technology for each mobile host in heterogeneous wireless networks as an optimization problem. To model this problem, we use Integer Linear Programming and show that it is NP-hard.
SCOPE
Our project focuses on resource allocation in heterogeneous multicast networks through a bandwidth-efficient multicast mechanism. This mechanism allows for more mobile hosts to cluster together, resulting in the use of fewer cells and saving scarce wireless bandwidth.
Furthermore, the multicast tree paths connecting to the selected cells share more common links, which helps to save wire line bandwidth. Our mechanism supports dynamic group membership and offers mobility for group members in heterogeneous wireless networks. We formulate the selection of the cell and wireless technology for each mobile host as an optimization problem and use Integer Linear Programming to model it. We show that this problem is NP-hard. To solve it, we propose a distributed algorithm based on Lagrangean relaxation and a network protocol based on this algorithm.
The simulation results show that our mechanism can effectively save wireless and wireline bandwidth compared to traditional IP multicast. This is achieved by selecting the cell and wireless technology for each mobile host to join the multicast group. As a result, the bandwidth cost of an Internet Protocol multicast tree will be reduced.
Modules display as follows:
In this module, we provide the number of nodes required in the network. Once our requirement is provided, a group of nodes gets arranged randomly in each cell. Each cell accesses the nodes according to its capability. Resource allocation involves finding the nearest tower to the mobile and then finding the nearest tower to that. The main advantage of this is to use available bandwidth and connect the mobile to the nearest tower.
To maintain good bandwidth usage, we need to choose the source and destination nodes in this module. Once the source node is entered, its position and the cell containing it are stored. Similarly, we find the position of the destination node to determine the shortest path.
In the Lagrangean path module, we divide the problem into two sub-problems. The first sub-problem helps us find a method for accessing the nearest cell while the second sub-problem determines bandwidth consumption. Finally, through Lagrangean iteration process, we can obtain the shortest path to access mobile devices.
Literature Review
The Mobile Multicast Protocol is supported by Mobile IP, which provides (unicast) IP routing for mobile hosts within an IP internetwork. The c m t version of Mobile IP offers two methods for supporting mobile multicast: remote subscription and bi-directional tunneling. In remote subscription, each Mobile Host (MH) must re-subscribe to its desired multicast group whenever it enters a foreign network. This requires the addition of its multicast router (MR) to the multicast distribution tree.
The update frequency of the multicast distribution tree will depend on how often the mobile handoff occurs. The main advantage of this approach is that the multicast datagrams are always delivered on the shortest paths. However, there is an overhead cost of reconstructing the delivery tree while a handoff occurs. In bi-directional tunneling, the mobile host receives multicast datagrams through its home agent (HA) using unicast Mobile IP tunnels. This approach hides host mobility from all other members of the multicast group.
In addition, the multicast distribution tree will not be updated for member location changes. The main drawback of this approach is that the routing path for multicast delivery may not be optimal. Additionally, the Home Agent (HA) must replicate and deliver tunneled multicast datagrams to all its Mobile Hosts (MHs), regardless of which foreign networks they reside in. This results in wasted network resources. The scheme is complicated by a phenomenon called tunnel convergence problem, which occurs when multiple Mobile IP tunnels (from different HAs) terminate at a particular Foreign Agent (FA).
When multiple hosts happen to have mobile devices that are members of the same multicast group at a foreign network managed by the foreign agent FA, more than one copy of every multicast package would be forwarded to the FA by every HA. To address this issue, Range-Based Mobile Multicast (RBMoM) [6] intends to trade off between the shortest delivery path and the frequency of multicast tree reconfiguration. Multicast datagrams are delivered on near-shortest paths without incurring high costs for reconstructing the multicast tree (the main drawback of remote subscription).
RBMoM, like the home agent in Mobile IP, has a router called mulficasf home agent (MHA) responsible for tunneling multicast datagrams to the foreign agent where the mobile host (MH) is currently attached. Therefore, each MHA must always be one of the multicast group members. This is similar to bi-directional tunneling where every home agent must join the multicast group. Each MH can only have one MHA, and its HA never changes. However, the MHA of an MH can change based on its location. The initial MHA of a mobile host is set to be its HA.
RBMoM addresses the concept of range” for each MHA. The range of an MHA refers to the service area for its mobile hosts. In other words, an MHA can only serve mobile hosts that are within its service range while roaming around foreign networks or the network to which it is attached. If a mobile host is outside of its MHA service range, a handoff will occur, and another MHA will take over the multicast service for that mobile host. From the perspective of the range concept, we can see that both bi-directional tunneling and remote subscription represent extremes of BMoM. Let R be the service range of a multicast home agent.
Thus, if we let R = m, then RBMoM is the same as bidirectional tunneling with a range of 0 to 1. In this case, the MHA always serves as the home agent and is never changed. On the other hand, if we let R = 0, then RBMoM is equivalent to remote subscription. This means that when an MH enters a foreign network (i.e., handover), its MHA must be changed due to being out of service range.
RBMoM serves as a generalization of these cases and unifies mobile multicast approaches. Based on the value of R, a MHA can determine whether datagrams should be tunneled to each host. Note that the service range restricts the length of tunnels between mobile hosts and their respective MHAs.
The Range-Based Mobile Multicast Forwarding Mechanism is implemented on all routers in Figure 4. If Router RT has been elected as the MHA for the Campus Network, it can service RT2 and RT with a range of 1. For simplicity, we assume that mobile hosts MH through MH5 join the same multicast group and there is only one source. The base stations in SubnetA and SubnetB join this multicast group via the Internet Group Management Protocol (IGMP). Similarly, using IGMP, routers and base stations in the Campus Network would join this multicast group.
We assume that RT and RT3 are served by the same MHA, which is RT (i.e., RT is the MHA of both RT2 and RT3). It’s important to note that if other MHAs are within the service range of RT2 and RT, they can also be served by those MHAs. However, each multicast router must elect only one MHA. This means that each router can have only one MHA even if there are multiple MHAs in its neighborhood. To illustrate how a multicast datagram is delivered, let’s suppose that a Multicast Source (attached to the Internet) sends a multicast datagram to the multicast group X”.
This datagram will be sent through the Internet to the MHA (Router RT) using a multicast routing protocol such as CBT, DVMRP or PIM. Then, RT forwards the datagram to members of multicast pup X located at SubnetA and SubnetB. This is achieved by sending a single copy of the datagram onto Campus Network as a data-link layer multicast. Upon receiving the multicast datagram from RT, RT2 and RT will then multicast it on their connected networks (SubnetA and SubnetB respectively). Note that if MH2 moves from the area of BS to the area of BS, it can still receive the multicast datagrams since it is within the service range of the same MHA (RT).
When migrating to the area of BSI, the result will be similar because BS is still served by RT. Therefore, there are almost no datagram losses due to mobile host handoff as long as the mobility is within the service range of the MHA (i.e., host mobility is hidden within MHA’s service range). The election for multicast home agent (MHA) is performed per handoff by a mobile host using a combination of distance tiebreakers (i.e., the closest node to the multicast source should be MHA) and loading tiebreakers in case of equal distances.
When both distance and loading are equal to 161, random tiebreakers will be used. To simplify the process, all mobile hosts within a subnet can have the same MHA, which must be a multicast router. This solves the tunnel convergence problem. RBMoM elects the MHA from a group of multicast routers with hop distances less than or equal to R for a given service range R. Mobile hosts on a common LAN share the same MHA. The network topology assumes that each LAN has an MR and every node in this figure represents a LAN (or subnet). Service range = 1.
The MR in a squared” LAN (e.g., LAN 2, 5, and 9, etc.) refers to the qualified router that can act as an MHA. Once a qualified router is elected as an MHA, it must be on the multicast tree. For instance, if the MR at LAN 2 (denoted MR1) acts as the MHA of LAN 1,3 and 7, it must be on the multicast tree to receive multicast datagrams from some source. Then it will tunnel these received multicast datagrams to MR1, MR2 and MR3 which will further broadcast them to their local mobile participants. Within service range there are two possible candidates for its MHA (i.e., MR1 and MR2).
We choose the one that saves fewer MRs to be the MHA (loading tiebreakers). If the loading is equal, we can use random tiebreakers to choose one. Increasing the service range obviously decreases the number of MHAs. How can we get qualified MRs in the example mentioned above to be candidates for MHAs for a given service range and network topology? We need to develop an algorithm to elect a set of MRs so that every LAN can decide its MHA from this set with the constraint of service range (i.e., the MHA must be within service range). Here, we assume there is only one MR in each LAN.
The set obtained from the algorithm should be as small as possible to reduce multicast traffic on the tree. Additionally, delivery paths must be kept short. To solve this problem quickly and get an acceptable answer, we will use a distributed greedy algorithm instead of an optimal one. We model the network topology as a graph where each node represents a LAN and an edge between two nodes means that both LANs are adjacent. It is important to note that in our algorithm, neighbors” refers to the set of nodes within the radius of the service range (known as “locally”).
There is a variable used to record whether this node is a member of the set of candidate MHAs. Its initial value is null. During runtime, the status can hold one of three values: null, non-member, or member. When the algorithm ends, the status must be either member” or “non-member”. The MRs at the “member” nodes (LANs) are possible MHA candidates. Each LAN can randomly choose one to be the MHA but must meet service range constraints. Once an MHA is decided upon, it cannot be changed during the multicast session.
At the start of the process, each node broadcasts its degree (i.e., the number of adjacent nodes) to its neighbors. The TTL (Time-To-Live) field in the IP header can limit the scope of this broadcast message. For a node, excluding non-member and holding nodes in its locality, if slatus = null and it has the highest degree in its locality, it becomes a member node. Thus, sfafus = member and broadcasts a MEMBER message to its neighbors using lowest-ID tiebreakers. When receiving a MEMBER message, a node whose status is not ready (i.e., neither member” nor “non-member”) sets its stam as “non-member” and broadcasts a NON-MEMBER message to its neighbors.
If a node’s status is not ready and there exists a non-member adjacent node, its SFaim is set to holding” (temporary status), and it sends a “HOLDING” message to its neighbors. If a node’s status is “holding,” and all other nodes’ statuses in its locality are either non-member or holding, the status can be changed to member if it has the highest degree among all holding nodes in its locality. Lowest-W tiebreakers are also used here. Like the above rules, the status update needs to inform all nodes in its locality.
SYSTEM ANALYSIS AND DESCRIPTION
Existing System
The existing system of this project consumes more bandwidth for the Internet Protocol multicast tree and does not support dynamic groups of members or the mobility of group members. Most previous works for mobile multicast in heterogeneous wireless networks focus only on efficient mechanisms to provide seamless handover between different networks and related security issues. However, there are no existing systems that deal with problem 3.
Proposed System
The aim of the proposed system is to reduce the bandwidth cost of an internet protocol multicast tree. This can be achieved by adaptively selecting the cell and wireless technology for each mobile host to join the multicast group. The shortest path can be found, which reduces bandwidth consumption in the shortest path tree in heterogeneous wireless networks because routing is more flexible. The shortest path tree in heterogeneous wireless networks consists of two parts.
The first aspect of the routing process involves the cell and wireless technology selected by each mobile host. The second aspect is the wired links connecting the root of the tree to the chosen cells. By selecting different cells and wireless technologies for mobile hosts, we can alter the routing of the shortest path tree and reduce bandwidth consumption. This selection process is known as an optimization problem, specifically referred to as Cell and Technology Selection Problem (CTSP), in heterogeneous wireless networks for multicast communications.
We need to select the appropriate cell and wireless technology for each group member in order to minimize the total bandwidth cost of the shortest path tree. To achieve this, we have designed a mechanism.
Feasibility Study
In this phase, the feasibility of the project is analyzed, and a business proposal is presented with a general plan for the project and cost estimates. As part of the system analysis, a feasibility study of the proposed system must be conducted to ensure that it will not burden the company. To perform a feasibility analysis, it is essential to have an understanding of the major requirements for the system.
This study aims to assess the economic impact of the system on the organization. Due to budget constraints, the company’s investment in research and development for the system is limited. Therefore, all expenditures must be justified. Fortunately, we were able to develop the system within budget by utilizing mostly freely available technologies. Only customized products had to be purchased.
This study is being conducted to assess the technical feasibility of the system, specifically its technical requirements. It is crucial that any developed system does not put a strain on the available technical resources, as this would result in high demands being placed on the client. Therefore, it is essential that the system’s requirements are modest and require minimal or no changes for implementation.
The purpose of this study is to assess the user’s acceptance level of the system. This involves training the user to efficiently use the system without feeling threatened by it, but rather accepting it as a necessity. The level of acceptance depends on the methods used to educate and familiarize the user with the system, which should increase their confidence and ability to provide constructive criticism as they are ultimately the end-users.
The Incremental, Iterative Software Engineering Life Cycle
When defining and constructing credit card validation systems, we may uncover many requirements that are difficult at the outset. However, knowledge of the system and requirements will grow as work progresses. The whole software engineering process is designed to uncover details and incompatibilities in the requirements that may not be obvious to customers and bankers at the outset.
During several cases or increments of software development, additional increases will be built and delivered in successive increments. This system normally involves delivering successive new versions. The development of the first version starts from scratch.
The sketch called Green Field Development is a special case of incremental development. The development of the first increment is an important activity series, where we establish the architectural base that must last for the entire system’s lifetime.
The Waterfall Lifecycle Model states that the phases (analysis, design, coding, testing, and support) are systematized in a linear order. Each phase should be accomplished entirely before the next phase begins.
The step-by-step analysis phase is completed, and the output is generated at the end of this phase. This output becomes input for the design phase, which generates all design steps based on the inputs. All phases are processed in this way, producing successful outputs. The purpose is to determine whether the project is following the correct path or not. If it’s not, then corrective action may be taken or even discarding of the project altogether. This model is commonly used and known as a linear sequential lifecycle model.
The CLR uses the Common Type System (CTS) to strictly enforce type-safety. This ensures that all classes are compatible with each other by describing types in a common way. CTS defines how types work within the runtime, enabling types in one language to interoperate with those in another language, including cross-language exception handling. In addition to ensuring that types are used appropriately, the runtime also prevents code from attempting to access memory that hasn’t been allocated to it.
The Common Language Specification
The CLR provides built-in support for language interoperability. To ensure that managed code can be fully used by developers using any programming language, a set of language features and rules called the Common Language Specification (CLS) has been defined. Components that follow these rules and expose only CLS features are considered CLS-compliant.
