So far in this chapter, we have discussed the various mechanisms and procedures that effect the routing of data packets to a mobile device. We have concentrated on the message types and the message exchanges. We have not discussed the data structures necessary to support these functions. In many ways, the CDPD system operates a distributed data base to manage the location information of all the mobile users, which is analogous to conventional router networks.
In this section, we will discuss three of the databases that are concerned with mobility management within the CDPD network. Although there are other equally important data structures, such as subscriber profile information within the network, we shall not discuss them.
The first data structure we discuss here is the Home Domain Directory. Even though it is an essential part of the network, casual observers of the network may not be aware of its importance, or at least unfamiliar with how this data base is initiated and maintained.
When a mobile device initiates a registration request with the CDPD network, it provides its NEI to the serving MD-IS. Given this NEI, the serving MD-IS must pass the supplied associated authentication credentials to the appropriate home MD-IS for validation. The question is then, how does a serving MD-IS determine the proper home MD-IS for this particular NEI? The Home Domain Directory maintained at each serving MD-IS provides this information.
To support the large and increasing number of mobile NEIs within the CDPD network, it is not sensible to provide a one-to-one lookup table for each and every possible NEI. Instead, the Home Domain Directory is maintained as address ranges. Each Home Domain Directory entry consists of a tuple of three values. The first two values are NEI address and an associated address mask. The combination of the two values allow the system to establish a NEI address range. The third value in the tuple is the address of the associated Mobile Home Function. This is the address of the function within the home MD-IS responsible for any NEI that falls within the NEI address range.
In normal operation, the mobile unit starts by initiating the registration of a specific NEI. The M-ES sends an ESH message to the serving MD-IS containing the NEI and its associated authentication credentials. The serving MD-IS, on receipt of the ESH message, examines its Home Domain Directory for a match between the address range and the supplied NEI. Once the correct tuple is located, the associated Mobile Home Function address is used as the destination address of the constructed RDR message.
This mechanism requires that the Home Domain Directory be complete. If the Home Domain Directory is incomplete, registration attempts with unrecognized NEIs cannot be serviced. However, with the large number of NEIs anticipated and the expected growth of the CDPD infrastructure, it is unreasonable to expect all serving MD-ISs to be manually updated with the most up-to-date home domain information. There must be support for dynamically updating Home Domain Directory information.
In the CDPD system, the concept of dynamic updates to the Home Domain Directory is supported through an optional data field in the Redirect Confirm (RDC) message. This is best illustrated through an example scenario.
In the following example (see Figure 4.19), all NEIs within the address range of 198.76.0.0 to 198.76.255.255 (hexadecimal C6.4C.00.00x to C6.4C.FF.FFx were originally homed at a Mobile Home Function with address 198.12.34.56 (hexadecimal C6.0C.22.38x). As the network grew, the home domain was partitioned into separate devices such that a new MHF was added. This new MHF acts as the home for NEI address range 198.76.80.0 to 198.76.95.255 (hexadecimal C6.4C.50.00x to C6.4C.5F.FFx) and has an address of 198.12.34.58 (hexadecimal C6.0C.22.3Ax).
Now when a mobile unit with address 198.76.84.32 (C6.4C.54.20x) registers with the serving MD-IS, the Home Domain Directory at the Mobile Serving Function (MSF) has not yet been updated with the new MHF information. The MSF thus examines its Home Domain Directory entry and finds a match in the original entry. The Mobile Serving Function sends an RDR message to the original MHF of 198.12.34.56 (C6.0C.22.38x). The original MHF now forwards the RDR to the new MHF. The new MHF has the option of responding with an optional field in the RDR message. This optional field contains the new HDD tuple for future use. This would contain an NEI address of 198.76.54.32 (C6.4C.50.00x), an address mask of 255.255.240.0 (FF.FF.F0.00x).
On receipt of the RDC from the new MHF, the MSF updates the Home Domain Directory to reflect the updated home domain information. This is illustrated in Figure 4.20. It is imperative that the search order through the HDD is managed correctly. The MSF must search through the HDD in ascending order of generality. In other words, it must check for address matches that are more specific in nature prior to matches of wider scope. This is analogous to conventional routing tables.
In the example, a mobile registering the address 198.76.84.32 (C6.4C.54.20x) must be matched with the HDD tuple 35. If the MSF manages the search order such that it attempts to match the NEI with tuple 35 prior to tuple 36, the correct match would be detected. If the MSF attempts the match with tuple 36 prior to tuple 35, then the resultant RDR would be sent to the original, and incorrect MHF.
Now the question begs, how does the HDD get established initially? The intent in the CDPD Network is to establish a central addressing authority, the CDPD Network Information Center (CDPD NIC). This authority is responsible for the assignment and allocation of network addresses for all CDPD network service providers.
As each CDPD network service provider initiates its service offering, it registers its address allocation with the CDPD NIC. At the same time, the service provider registers an initial default MHF address. The service provider may also attain the current initial HDD containing all the default HDD tuples of the existing registered CDPD service providers. At this time, this process is still in development. The final operating procedure may deviate from this initial concept.
The next data structure to be considered is the Registration Directory. This is the data base maintained by the Mobile Serving Function to track the location of each mobile network address within its routing domain.
The Registration Directory (Figure 4.21) is the repository of information that associates each registered NEI with the channel stream it is operating on. The Registration Directory tuples consists of the mobile unit's NEI, the mobile unit's subnetwork address, and a registration sequence counter value.
The Mobile Serving Function uses the Registration Directory for two main purposes. The first use is as a routing table for data packets routing towards the M-ES. When the MSF receives a data packet destined for a mobile unit, it first decapsulates the forwarded packet from the Mobile Home Function. The MSF then examines the NEI of the decapsulated packet and searches its Registration Directory to determine the proper subnetwork address for packet redirection.
For data packets in the reverse direction, the Mobile Serving Function uses the Registration Directory to verify that the NEI is a valid registered address. On receipt of a data packet from the M-ES, the MSF compares the source address in the data packet and the subnetwork address against the entries in the Registration Directory. There must be a match in the Registration Directory.
If there is a match with an entry in the Registration Directory, the received data packet is submitted to the data network for eventual routing to its destination. If no match is found in the Registration Directory, the data packet is discarded and will not be routed. This procedure is to ensure that mobile devices cannot inject data traffic into the network with fraudulent addresses.
The registration counter value is used to reduce the possibility of varying network delays resulting in a registration error. This may be the result of a mobile unit relocating from one routing area to another while in the midst of a registration attempt. An example is a mobile initiating a registration attempt in routing area A, then due to movement, relocates immediately to routing area B. The mobile may have sent an ESH message in routing area A and immediately initiated another ESH message in routing area B.
In this instance, if the home MD-IS receives the serving MD-IS generated RDR messages in the same order, that is the RDR from routing area A arrives prior to the RDR message from routing area B, no confusion results. However, if the RDR message from routing area A suffers a longer transit delay and arrives after the RDR message from routing area B arrives, then the Mobile Home Function may be led to believe that the mobile unit has exited routing area B and re-entered routing area A!
To reduce this type of error, the mobile unit increments a registration counter value on each successive registration attempt. The registration counter value is included in the ESH message. The serving MD-IS, on receipt of the ESH message, records the registration counter value, and includes it in the generated RDR message to the Mobile Home Function. This allows the MHF to ignore RDRs that have been delayed and arrive out of sequence.
This shows why it is necessary for the MHF to maintain the registration sequence counter value. It does not immediately explain why the MSF must also maintain a record of the registration sequence counter value. There are really two reasons. The first purpose of the MSF maintained registration sequence counter value allows a Mobile Home Function to issue a Redirect Expiry (RDE) message to specifically release an out of date Registration Directory entry without fear of inadvertently deleting a new registration attempt by the same mobile NEI.
The second use of the registration sequence counter value in the Registration Directory is related to the possible networking connection between the RF cells and the serving MD-IS. While the original intent was for the serving MD-IS to be geographically close to the base sites, the specifications allow these to be separated by large distances and interconnected through an extensive routing network. In such configurations, it is necessary to protect the Mobile Serving Function from being misled by ESH messages that arrive out of sequence from different cells.
The Location Directory is the data base that is maintained by the Mobile Home Function. It's main purpose is to act as the routing information table for the MHF to determine the address of the readdress server for each mobile NEI.
The Location Directory (Figure 4.22) associates each M-ES NEI with the readdress server forwarding address. This is the address to forward the encapsulated data packets for the identified NEI. On receipt of a data packet destined for a mobile NEI, the Mobile Home Function consults its Location Directory. If an entry with the requested NEI is found, the MHF encapsulates the data packet and redirects the packet towards the readdress server forwarding address indicated in the Location Directory. If there is no entry found in the Location Directory matching the destination address of the data packet, the requested mobile NEI is not registered and the data packet is discarded. The Mobile Home Function may return an ICMP packet to indicate the inability to deliver the packet.
The registration counter value is maintained in the Location Directory to reduce the possible incorrect routing of packets due to varying delays encountered by RDR messages from different Mobile Serving Functions. This mechanism is described in the preceding section.
Unlike the Registration Directory, the Location Directory information is not involved in the relay of traffic initiated from the mobile unit. This is because the data packets sent from the M-ES need not traverse the Mobile Home Function prior to delivery to their destination.
Figure 4.22 illustrates two separate NEIs being associated with a single readdress server forwarding address. In practice, there are likely to be a large number of NEIs associated with each readdress server.