Apparatus and method for efficient delivery of multicast data over a personal access communications system (pacs)

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

The present invention relates to a system and method for performing mobile cellular communication, and more particularly to a method and system for Internet services in a mobile cellular communication network.

[Conventional technology]

To date, cellular mobile and wireless communication systems have been designed and configured for voice services. Due to the rapid increase in Internet applications and users, there is an increasing demand to provide Internet services to mobile users based on existing cellular systems. Voice communications are characterized as connection-oriented, circuit-switched, constant bit rates and low tolerances for loss and jitter. In contrast, Internet services feature disconnected communications, packet switching, bursty traffic patterns, multicast, a large number of class distinctions of services, and often best effort and loss-tolerant communications. In addition, some Internet applications often desire much higher on-demand bandwidth, such as video conferencing using variable bit rate coding. To date, in addition to the existing infrastructure of voice-oriented cellular networks, the development of economical network architectures, as well as the system components needed to meet these different demands of Internet services, has yet to be achieved. It is a goal.

【0002】

Figure 1 shows the PACS (Personal Access Communication System) 100. PACS is a new low-tier, low-cost PCS standard for cellular wireless services in densely populated areas. The PACS standard defines two data communication modes (line mode and packet mode).

【0003】

In the PACS network, the user is serviced by the subscriber unit (SU) device 102. The SU102 communicates with a radio port (RP) via a time division multiple access (TDMA) uplink and a time division multiplexing (TDM) downlink. The range of influence of RP104 and the range of influence of SU102, which are determined by their transmission and reception ranges, define cell 112.

【0004】

The nearby RP104 is controlled by a radio port controller (RPCU) 106 that collects all traffic from the RP104 and connects it to the backbone voice or data network. User authentication and other related functions are performed by Access Manager (AM) 108 and Signaling Network 110.

【0005】

The packet mode data service of the PACS standard functions as a basic building block for implementing and managing IP services in the Internet service architecture of the present invention.

【0006】

PACS Packet Mode Data Services, known as PACS Packet Channels (PPCs), provide variable bandwidth, asynchronous, on-demand bandwidth and asymmetric data services up to 256000 bytes per second (Kbps) of data. Provide users at speed. It is based on frequency division multiplexing. The TDMA uplink and TDM downlink PACS physical interfaces are common to both line-mode and packet-mode services. The uplink is the direction from SU102 to RPCU106 and the downlink is the direction from RPCU106 to SU102. The high data rate and variable bandwidth properties of PPC are well suited to the multimedia and bursty properties of Internet traffic. The PPC supports dynamic sharing of bandwidth with PACS line mode services (voice, line mode data, etc.), otherwise allows the PPC to use idle bandwidth.

【0007】

A in FIG. 2 is a schematic diagram showing the hierarchy of PPC. This PPC consists of three layers: PACS physical layer 202, data link layer (DL) 204 and security layer (SL) 206. The PACS physical layer encodes TDMA uplinks and TDM downlinks. Both uplink TDMA and downlink TDM have a frame length of 2.5 seconds. Each frame consists of 8 slots, each slot being 10 bytes long. The task of PPC DL Layer 204 is to provide reliable disconnected communication services to SL Layer 206, which includes Medium Access Control (MAC), fragmentation and segmentation, and error detection and correction. There is. The main functions of SL layer 206 include handset registration, user authorization and data encryption.

【0008】

Figure 2B shows the PACS standard encapsulation and frame instruction procedure. First, the PPC copies each network layer packet 210 in SL packet 212 with header 214 and checksum 216, with optional payload encryption to prevent eavesdropping by radio waves. It then encapsulates each SL packet 212 in a DL packet 218 with the appropriate header 220 and checksum 222. Each DL packet 218 is split into one or more DL fragments 224, and finally each DL fragment 224 is subdivided into DL segments 226. Fragmentation is for high-level media access capabilities, and the PPC must assign a slot number (from 8 slots) to each DL fragment 224. All segments of a fragment 224 must be transmitted in the same slot. Segmentation is for conforming to the TDM / TDMA radio link structure, which is shown in C in Figure 2.

【0009】

Due to downlink fragmentation, the maximum fragment size is 576 bytes of data. Larger packets must be fragmented, but each fragment can be sent in parallel in different slots. The uplink fragment may be 256 segments long, so packets 218 of all uplink DLs are sent in a single fragment.

【0010】

Figures 3 and 4 are schematics showing the encapsulated uplink and downlink messages in more detail.

【0011】

FIG. 5 is a schematic diagram of the functional architecture of the PPC. Contention Function (CF) 302 provides a small subset of DL media access and acceptance procedures that are very time critical. The Packet Data Controller (PDCU) 304 handles the rest of the DL and SL functions. CF302 is present in RP104 and PDCU304 is generally configured in RPCU304.

【0012】

Each packet mode SU102 has a subscriber identity (SubID). This sub ID is used to authenticate the user during registration. In addition, each active SU102 also has a transient identifier called the LPTID (Local Packet Terminal Identifier). The LPTID is a 1-byte integer that identifies the source / destination SU102 in any uplink / downlink slot by radiolink. The SU102 is assigned a unique LPTID each time it enters cell 112 (by cold start or roaming) as long as it remains in that cell 112. The LPTID is valid only in the current cell 112 and the SU102 can have different LPTID values in different cells 112. The LPTID will be assigned by PACS Network 100 after successful registration and will be reassigned after each handoff. When SU102 moves to an adjacent cell, the old LPTID is no longer used and the new LPTID is in the new cell 112 Must be assigned in. Therefore, LPTID is actually transitional. Table I below shows the current allocation scheme for LPTIDs as defined in the standard. Table I LPTID value objective 0 × 00 null 0 × 01 Registration message (SU102 is assigned LPTID Used before) 0 × 02-0 × EF Assigned to SU102 during registration and handoff.

【0013】

This allows up to 238 SU102s in each cell 112 Is possible. 0 × F0-0 × FD Reserved for future use 0 × FE system information (data link layer, network layer and To broadcast "system information channel" parameters Used) 0 × FF All SU102 (unless broadcast to all SU102) Used for messages that shouldn't be After successful registration, each active SU102 is assigned a data link layer address for use in the current cell 112. This data link layer address is a 1-byte integer called LPTID (local packet terminal ID).

【0014】

SI102 performs PPC registration whenever it enters the network. The two main tasks of PPC registration are authentication and LPTID assignment. At the beginning of registration, SU102 sends a registration request message (PACKET REG REQ) containing a sub-ID (assuming no user anonymity). AM108 then uses this sub-ID to authenticate SU102. Upon successful authentication, PDCU304 assigns a new LPTID and sends an acknowledgment message (PACKETREG ACK) back to SU102 with this LPTID. From that time on, SU102 identifies the data that is scheduled to be sent by LPTID until it is unregistered from the network or moved to a different cell 112.

【0015】

Cell handoff is known as automatic link transfer (ALT). ALT occurs when SU102 crosses the boundary of radio cell 112. It begins when SU102 detects the degradation of the current physical channel and finds another physical channel of sufficiently high quality. The SU102 then sends an ALT request message to the new RP102. Upon receipt of this request, SU102 regains the ALT execution message and gets a new LPTID for the new cell 112. Depending on whether two channels are assigned the same RPCU106, the ALT will be the ALT in the RPCU if the SU102 is moved to an adjacent cell in the same RPCU106, and the RPCU if the SU102 is moved to a different RPCU106. It can be divided into two categories, ALT.

【0016】

[Problems to be Solved by the Invention]

So far, PACS100 has been developed mainly as a voice network. The standard specifies two data communication modes (line mode and packet mode), but does not address the issue of Internet service support in PACS100. Internet access can be provided by Line Mode Data Services if the user configures a Point-to-Point Protocol (PPP) connection to an Internet Service Provider (ISP) via a dedicated PACS channel. However, due to the fixed bandwidth, this type of access cannot be scaled and is inefficient for Internet applications.

【0017】

There is a need for a network architecture and a set of design guidelines that seamlessly integrates cellular networks with the global Internet by supporting mobile and multicast IP services in cellular networks. The present invention satisfies this need.

[Means for solving problems]

To solve the above-mentioned needs and requirements problems, the present invention discloses a new system and network architecture for PACS networks. It augments the PACS voice network with IP routers and backbone links to connect to the Internet or intranet. In addition, mobile IP is included in the handoff mechanism to support roaming within the PACS network, as well as worldwide mobility between the PACS network and the rest of the Internet / intranet. The present invention also discloses the use of unique PACS multicast and group management schemes to support dynamic IP multicast and multicast backbone (MBone) connectivity.

【0018】

These features seamlessly integrate existing PACS networks into the global Internet to provide standards-compliant IP services with worldwide mobility support. The system allows PACS users to access wireless Internet using a prototype packet mode SU connected to a personal computer (PC) on a mobile. Most IP applications can behave as if a mobile personal computer is a fixed Internet host.

【0019】

Users and mobile PCs can roam within the PACS wireless network or move between the PACS network and the external Internet using mobile IP. IP multicast and MBone applications are also seamlessly and efficiently supported using unique PACS multicast.

【0020】

In addition, the present invention extends the functions of a device called a packet transfer module configured in an RPCU and related elements to enable efficient one-to-many (multicast) communication between PACS users in a PACS wireless network. The methods and devices to achieve are disclosed. The system design and architecture for SU to support multicast is also disclosed. A mechanism added to the packet forwarding module and SU to (1) dynamically map between global multicast addresses and local PACS group addresses, and (2) forward multicast packets only to cells with at least one group member. Selective multicast for, and (3) efficient group membership management is realized.

【0021】

Multicast extensions offer some advantages over current systems. First, it delivers only a single copy of the multicast packet to PACS group members. Second, multicast packets are not sent to cells that do not have group members, thus saving broadcast time. PACS bandwidth usage is optimal because PACS multicast delivers exactly one copy of data per cell only to PACS users who are members of the group, and power for PACS users who are not members of the group. Is not wasted (because they do not process multicast data). Third, any network layer multicast scheme (IP multicast and CDPD multicast) can be seamlessly supported. Finally, the expansion keeps group members efficient and accurate.

【0022】

The present invention also discloses methods and devices for multicasting data. The method of the present invention assigns a multicast packet terminal identifier to a multicast group when a subscriber device in the cell requests membership in the multicast group, receives a multicast packet with a global multicast address, and at least one multicast local. It has a step of determining a cell identifier from the mapping of the packet terminal identifier and the global multicast address to the cell identifier, and forwarding the multicast packet to the cell according to the cell identifier.

【0023】

The device of the present invention includes a radio port control device having a packet data control device, and the packet data control device is coupled to a radio port configured to receive a multicast packet and a packet transfer module. The packet data controller includes an allocation module configured to assign a multicast local packet terminal identifier to a multicast group when a subscriber device in the cell requests membership in the multicast group. The packet forwarding module is configured to determine the cell identifier from the mapping of at least one multicast local packet terminal identifier and the global multicast address of the multicast packet to the cell identifier. The packet forwarding module also forwards the multicast packet to the cell according to the cell identifier.

【0024】

The present invention results in (1) a PACS system architecture that provides wireless Internet and Internet access by augmenting the voice network with IP routers and backbone links to connect to the Internet, and (2) easy service maintenance and IPv6. Simplified IPvCU design for migration to future IP standards such as (3) Efficient support for dynamic IP multicast and multicast backbone (MBone) connectivity through the use of unique PACS multicast. And (4) optimize mobile IP and include it in the PACS handoff mechanism to efficiently support roaming within the PACS network and global mobility between the PACS network and the Internet. ..

【0025】

BEST MODE FOR CARRYING OUT THE INVENTION

In the following description, reference is made to the accompanying drawings, which form part of some embodiments of the present invention and are illustrated by way of illustration. It should be understood that the use and structural changes of other embodiments can be made without departing from the technical scope of the invention.

[PACS Internet Service Architecture] FIG. 6 is a schematic diagram showing the PACS Internet Service Architecture (PISA). The PACS Internet Service Architecture 400 includes an existing PACS voice network 100 supplemented with a new data network called PPN (PACS Packet Network) 416. Subnet 418 is the basic subnetwork unit that supplies radio packet data to the SU102. IP subnet 418 contains one or more cells 112, one base station or RP104 per cell 112, and RPCU106 that connects all of the cells 112 to the wireless backbone interconnect network. The RPCU106 also acts as a network gateway and multicast server for subnet 418.

【0026】

Each RPCU106 is communicating with the Internet Protocol (IP) router 410. PPN416 is an internetwork that connects all IP subnets 418 with IP router 410 and backbone link 420. Border gateway (GW) 412 connects different PPN416s (from different PACS network operators) and global network 414. Each GW412 also includes firewalls and other security features to protect PACS network premises and PACS users. In the PISA400, a mobile personal computer (PC) with packet mode SU102 constitutes a legitimate host on the Internet / intranet with a unique IP address. The SU102 is a network device that provides mobile hosts with a wireless network interface to the Internet via a PACS network. PPN416 will be a large IP network.

【0027】

When a user subscribes to the PACS IP service from a network operator, the SU102 is assigned a permanent IP address from the "home" network. When a user connects a personal computer PC to the SU102, the PC uses this IP address as the host address when accessing the Internet. In this regard, the home network is the IP subnet 418 served by the RPCU106, which users probably use most of it. The network operator records its permanent IP address in its database that can be retrieved later by AM108. For each SU address IP datagram sent to this IP address, PPN416 can forward the packet to the home subnet 418. The corresponding RPCU106 then sends it to the target SU102 when the user is currently in the home IP subnet 418. IP datagrams leaving the SU102 (SU source) are forwarded by the RPCU106 to the IP router. PPN416 Unicast routing in, ensures its correct delivery across the PPN416 and the Internet. The processing when SU102 moves out of the home IP subnet 418 will be described later.

【0028】

From an IP network perspective, the RPCU106 and its RP104 act like an intelligent link-layer router / bridge between the IP router 410 and all mobile IP hosts (SU102). This architecture hides PACS-specific details from the IP Router 410 so that it can use any commercial off-the-shelf (COTS) product. The connection between the RPCU106 and the IP router 410 can be any type of data network, such as Ethernet or Frame Relay. Many routers support many IP subnets 418, so one RPCU106 per router port allows one IP router 410 to connect many RPCU106s.

【0029】

This network architecture is significantly different from traditional communication networks. Asynchronous Transfer Mode (ATM) communication is generally considered to be the backbone of third-generation wireless communication networks, but IP networks make a better choice. ATMs have proven to be inefficient in supporting Transmission Control Protocol / Internet Protocol (TCP / IP) applications and do not require an extra layer. The IP-based Internet is less expensive to install and administer. In addition, mobile management will be done at both the IP and ATM tiers. Although ATM mobility is under study, mobile IP has been standardized by the Internet industry and is supported by several products. The multicast mechanism for mobile IP is also excellent.

【0030】

The main function of the RPCU106 in the PISA400 is to send and receive IP datagrams to and from the SU102. The RPCU106 provides address resolution, framing and medium access, which are the basic network layer to data link layer interface functions.

【0031】

7 and 8 are block diagrams of one embodiment of the RPCU106 and related system elements. An important component of the RPCU is the Packet Forwarding Module (PFM) 402, which translates addresses from the network layer to the data link layer. Network layer modules, such as the IP Routing Function Module 532, handle the routing between PACS users and the backbone network.

【0032】

PISA400 uses LPTID as the data link layer address. To transmit SU address data such as IP datagrams in the downlink direction, PFM402 works in harmony with one or more packet data control units PDCU304 and manages LPTIDs. This is because the PFM402 must know that cell 112 (and associated RP104) has a SU102 receiver and the LPTID to use. Therefore, PFM402 maintains a mapping between IP addresses and tuples (RP identifiers, LPTIDs) for each SU102. In one embodiment, this mapping is stored as a table called the (unicast) address elucidation table (ART404) (the case of multicast is described below). ART404 is updated during user registration, ALT and deregistration. When an entry is found, PFM402 sends the RP identifier and LPTID information along with the IP datagram to the corresponding PDCU304, which PDCU304 is in cell 112 where SU102 is located. It is associated with the RP104 servicing.

【0033】

IP transfer of SU source data (from SU102 to RPCU106) in the uplink direction is performed as follows. PDCU304 receives the segment from RP104 serving cell 112 where SU102 is located and assembles the data link payload. When PDCU304 receives a complete IP datagram, it sends the datagram to PFM402. PFM402 checks if its datagram is targeted for another SU102 on the same subnet 418. If the datagram is targeted for another SU102 on the same subnet 418, RFM402 forwards the message using the same procedure as above. Otherwise, RFM402 forwards the IP datagram to routing module 532 for dissemination by the data link device 518 to the PPN backbone.

【0034】

The IP routing module 532 in the RPCU106 sends and receives messages to and from the Internet host via the data link device 518 to the PPN network 416. The IP routing module 532 may interface with a different type of data link device 518 and select the appropriate data link device 518 based on the linking technology used in the PPN backbone. The IP routing module 532 communicates messages received through the data link device 518 to the PACS device 536 over the IP router port 534.

【0035】

FIG. 8 is a block diagram showing another embodiment of the RPCU106. In this embodiment, the RPCU106 uses a modular method that includes two physically distinct hardware units, commercial off-the-shelf (COTS), an readily available IP router 538 and PACS device 536.

【0036】

Many COTS IP routers 538 support many connections with different data transfer protocols (for example, Ethernet or frame relay), and the data made available to PACS device 536 through IP router port 534 is these. You can follow any one of the protocols. At the same time, PACS Thebaid 536 does not generally follow a common data transfer protocol. Therefore, a stub 530 is provided between the IP router port 534 and the packet forwarding module 402. These stubs 530 make the necessary translations to translate messages from the data transfer protocol provided by IP router port 534 and the protocol required by PACS device 536. The stub 530 may be configured by a common local area network (LAN). Further, the stub 530 may include two stub elements in a form including one in the PACS device 536. In either case, the LAN device on the stub 530 is the packet forwarding module 402. Forwards data packets to and from any protocol and at least one of the required language translations.

【0037】

One advantage of this modular method is that changes to one device do not affect the other, allowing for easy and quick upgrades. For example, improvements to the mobile IP protocol affect only COTS IP router 538, while changes to PACS device 536 do not affect COTS IP router 538. As a result, new services and features can be created more easily. Also, using the COTS IP router 538 eliminates the need for data link device 518.

【0038】

In addition to the security layer, the SU102 includes the PPC module 506, which provides the same basic network layer and data link layer interface functions as the PDCU304 and CF302, including framing and medium access. However, since communication with any other host is always via the RPCU106, address elucidation is not necessary.

【0039】

The SU102 also translates Internet Protocol messages with the PACS Physical Layer Function (PLF) 504, which sends and receives data packets to and from the RP104, and the PACS Packet Channel (PPC) 506, which assembles received data packets into messages. Includes Internet Protocol Module 508.

【0040】

9 and 10 are flowcharts showing the above operation. First, a SU address data packet with an IP address associated with SU102 is received as shown in block 602. The SU address data packet is then translated from the router 532 protocol given to router port 534 to the protocol used by PFM402, as shown in block 604. The SU address data packet is then parsed to determine if an ARQ message is needed (block 606). If the message is loss-sensitive, the ARQ message is needed, and if the message is delay-sensitive, the ARQ message is not needed. The RP104 servicing SU102 is then identified from the mapping between the IP address of the SU address data packet and the RP104 servicing this SU, and that mapping is stored in ART404. PDCU304 then encapsulates and frames the SU address data packet as shown in block 614, and data segment 226. To generate. These data segments 226 are then transferred to RP104, which serves SU102, where they are sent to SU102, as shown in blocks 616 and 618.

【0041】

11 and 12 are schematics showing registration, handoff within RPCU106, handoff between RPCU106, and deregistration.

【0042】

The SU102 will perform a packet data service registration whenever it enters the PISA400. It does this by sending a registration message to the RPCU106 immediately after acquiring the physical channel. The registration message contains the SU102 permanent identifier sub-ID. The RPCU106 then sends it to AM108 for user authentication and authorization. At the end of registration, AM108 looks up the SU102's permanent IP address recorded during service delegation and returns it to PFM402. PDCU304 then assigns an LPTID from RP104, and PFM402 enters the IP address in the RP identifier and LPTID mapping in ART404.

【0043】

FIG. 11A is a schematic diagram showing SU102 registration. The SU102 will perform a PPC registration whenever it enters network 100. It does this by sending a registration message to the RPCU immediately after acquiring the physical channel. The two main tasks of PPC registration are authentication, authorization and LPTID assignment.

【0044】

At the beginning of registration, SU102 sends a registration request message (PACKET REG REQ) 702 containing its sub-ID to PDCU304 in RPCU106, which forwards the sub-ID to AM108. AM108 then authenticates SU102 with the sub ID. Upon successful authentication, AM108 looks up the SU102's permanent IP address recorded during service delegation and returns it to PDCU304. PDCU304 assigns a new LPTID and sends an acknowledgment message (PACKET REG ACK) 704 back to SU102 with this LPTID. The SU102 then identifies the data scheduled for this by LPTID until it is unregistered from network 100 or moved to a different cell 112.

[Handoff and mobility management] B in FIG. 11 and A in FIG. 12 are diagrams showing the handoff of SU 102. In PACS System 100, handoff is called automatic link transfer (ALT). ALT occurs when SU 102 crosses the boundary of radio cell 112. The ALT starts when SU 102 detects the deterioration of the current physical channel and finds another physical channel with sufficiently high quality. SU 102 then requests message 406 to the new RP 104 associated with the new PDCU 304B (PDCU 304 associated with the new cell 112).

【0045】

Once the request is received, the new PDCU 304 assigns a new LPTID and SU 102 gets an ALT execution message 408 and a new LPTID for the new cell 112.

【0046】

Based on whether the two channels are associated with the same RPCU 106, the ALT moves to two categories, the intra RPCU shown in Figure 11B, where SU 102 moves to the adjacent cell 112 of the same RPCU 106. It can be split into an ALT and an inter-RPCU ALT shown in A in Figure 12 where SU 102 moves to a different RPCU 106. The new PDCU 304 determines whether this is an intra-RPCU or an inter-RPCU by examining the full port ID (old RP) field of the PACKET REG REQ that contains the addresses of RP 104 and RPCU 106.

【0047】

In the case of the intra-RPCU shown in B in Figure 11, the new PDCU304B orders the PFM 420 to change the appropriate entry in the ART 404 that has access to the PFM 402, thereby making the SU 102 new. Indicates that you have been assigned an LPTID. The PFM 420 then orders the old PDCU 304A to release the previously assigned LPTID.

【0048】

In the case of the inter-RPCU shown in A in Figure 12, the new AM 108B of the new RPCU notifies the old AM 108A of the inter-RPCU ALT. The old AM 108A then orders the old PFM 420A to clear the IP entry and the old PDCU 304A to release the LPTID assigned to the previous cell.

【0049】

FIG. 12B is a diagram showing the deregistration process of SU 102. After the deregistration message (PACKET REG REQ) 710 sent from SU 102 is received by PDCU 304, an authentication request is sent from PDCU 304 to AM 108. AM 108 returns the IP address of SU 102 to PDCU 304. PDCU304 then releases the LPTID and orders PFM 402 to erase the IP address.

【0050】

In addition to the physical channel transfer and ALT processing described above, when SU 102 performs an ALT, PPM 416 must ensure proper transmission of the backbone of subsequent IP datagrams destined for SU 102. During the intra-RPCU ALT, SU 102 must have the same RPCU 106 and remain in the same IP subnet 418, so there is no impact on the transmission of PPN 416. Within the RPCU 106, the PFM 402 updates the ART 404 and replaces the corresponding entry with a new one containing the new RP 104 number and the new LPT ID. However, for the inter-RPCU ALT, not only must the ART table 404 of both the old and new RPCU 106 be updated, but the PPN 416's so that subsequent IP datagrams arrive at the new RPCU 106 instead. The process is even more complicated because the transmission must also be changed. This is achieved in the present invention by including the mobile IP in the PISA 400.

【0051】

Mobile IP is a standard Internet mechanism that allows the transmission of IP datagrams to a mobile host without considering the current attachment point of the mobile host to the Internet. To use Mobile IP, the Home Agent (HA) and Transfer Agent (FA) are configured in the IP transmission module 532 associated with RPCU 106, and the mobile IP client software runs on the mobile PC. Preferably, the COTS IP router 538 embedded in the mobile IP can be replaced by the IP transmission module 532.

【0052】

The present invention also includes a mechanism for improving wireless link efficiency when using mobile IP with PACS. Mobile IP client software typically relies on agent ads, or periodic broadcast messages from each FA, to detect changes in IP subnet 418 during handoffs.

【0053】

A in Figure 13 shows a message exchange during normal Mobile IP registration. Using the same mechanism of PACS has two problems. First, advertising messages waste valuable wireless link bandwidth in the absence of handoffs or registration activity. Second, this forces SU 102 to wait until the next advertising message arrives, resulting in an unnecessarily long registration time or handoff wait time. To fix this and at the same time protect the Mobile IP standard, PISA 400 includes Mobile IP Assistant Agent (MIAA) 512 in RPCU 106.

【0054】

B in Figure 13 shows the messages exchanged during mobile IP registration with PISA 400. MIAA 512 immediately sends an agent advertising message to the new SU 102 (advertising in demand) after the RPCU 106 completes the inter-RPCU ALT or fresh registration procedure. PDCU 304 piggybacks this message into a registration response message (PACKET REG ACK). This "piggyback" is an extension to the PACS standard, where the PACKET REGREQ message can piggyback network layer packets.

【0055】

The result is a one round trip savings between SU 102 and RPCU 106. In addition, each PACS mobile IP handoff activity is preceded by PACS registration or inter-RPC U ALT, eliminating the need for periodic agent advertising. Periodic Mobile IP Agent ads for each FA can be safely disabled.

[Multicasting] The access network must support one-to-many or many-to-many group communication called multicasting. In IP multicast, each group has a unique Internet address called the IP multicast address globally, and all group members are reached, so the multicast diagram is sent to the IP multicast address instead of the individual host address.

【0056】

Multicast or broadcast is limited to each cell that does not allow SU 102 to move between cells, and the PACS architecture has a very limited range of link-level addresses, so traditional subnet-wide link-level grouping. / Addressing structure is not applicable to PACS architecture.

【0057】

To solve this problem, the present invention limits the cell-wide grouping / addressing structure in which each cell 112 manages its own group and addresses independently of the other cells 112. The mapping of global multicast addresses to local group addresses is performed by dynamic mapping of global multicast addresses to vector of group addresses, each corresponding to a cell on IP subnet 418. It performs a selective multicast capability in which the RPCU 106 does not indiscriminately forward packets to all cells 112, but only to cells that have members. It binds to any multicast group on the Internet and provides each PACS user with the ability to receive multicast traffic from any source.

【0058】

IP multicast support in PISA 400 includes multicast transmission for PPN 416 and local multicast forwarding within each RPCU subnet 418. Multicast route configuration for PPN 416 is effectively achieved by adopting the multicast route configuration protocol used by Internet / M Bourn. Bourn is a collection of sites on the Internet that support IP multicast forwarding and enable live audio and video communication conferencing and more. Local multicast forwarding requires additional functionality in the RPCU 106 as described below.

【0059】

The basic requirement for PACS multicast is the link-level multicast address structure. Traditional subnets because PACS has a limited Link Layer Address Space (LPTID) compared to Class D IP addresses, and each PACS subnet 418 is partitioned into a number of cells 112 that independently manage LPTIDs. Wide link layer address structures (eg Ethernet) are not applicable in PACS. When multicast packets reach RPCU 106, which serves group members, the PACS specific multicast mechanism must send them only to members who are interested in the multicast group. This requires the ability of the local mobile host to combine cell-wide multicast groups and receive using the cell-wide group address assigned to the cell-wide group.

【0060】

PISA 400 meets these requirements with a cell-wide structure in which each cell manages a cell-specific group independently. The link layer address (LPTID) for an IP multicast group is the PACS group address for each cell 112 on subnet 418. In addition, PACS multicast must be selective in the sense that the RPCU 106 does not indiscriminately forward to all cells, but only one copy to each cell that has members.

【0061】

Different methods can be used on each cell 112 to send multicast by radio interface. One method is "multi-unicast", in which packets are replicated and sent as separate messages to each individual SU 102 who is a member of the group. Another method is a PACS broadcast where multicast data is transmitted in the broadcast slot to each SU 102 in the cell (by LPTID), where each SU 102 processes these and removes packets from uninterested groups. There must be. Unfortunately, the multi-unicast method is a simple method, but multicast is typically the most inefficient because it degrades many unicasts. This negates the benefits of multicast and wastes valuable wireless link resources. The broadcast method wastes the central processing unit (CPU) and the battery power of the SU 102, which is not a member of a particular group. The power consumption of the SU 102 is a big problem, so substituting it is not attractive.

【0062】

To solve the need for multicast communication without the drawbacks mentioned above, the present invention uses an extended PPC (PACS packet channel) that enables multicast capability with wireless link slot allocation. Normally, each downlink slot (except for control messages) is associated with an LPTID that identifies a unique target SU 102. The PISA 400 modifies the PPC, which allows one wireless link slot to be marked for a multicast group, receiving not only the slot assigned to SU 102, but other slots marked for one group. Strengthen SU 102 by its ability to do. In this way, all members of the group and only members can scan the slot process and receive multicast data without the need for replication or the use of broadcasts.

【0063】

To do this, PISA 400 extends the LPTID notion to include PACS cell-wide multicast groups. This address scheme uses a local multicast identifier, such as "multicast" LPTID, (m-LPTID), if it is assigned to a PACS multicast group instead of a particular SU 102. When the RPCU 106 wirelessly sends a multicast datagram over the air, it uses the corresponding m-LPTID on the downlink. The SU 102 can configure a receive interface (or PLF 504) with a list of LPTIDs, i.e. a unique LPTID assigned when the SU enters and registers in a cell and optionally a list of one or more m-LPTIDs. it can. The m-LPTID assignment is dynamic because the m-LPTID shares the same address space with regular or unicast LPTIDs. Allocation differs from (unicast) LPTID in two ways. First, m-LPTID is a large number of SUs in the same group Shared by 102, which is assigned only when the first group member of the cell requests to join the groups. Subsequent requests from other SU 102 will be assigned the same m-LPTID. Similarly, m-LPTIDs are only released after all members have left this group in cell 112. Second, m-LPTIDs can be reused in more than one multicast group at the same time. This is because the number of valid m-LPTIDs is usually very small compared to all possible IP multicast addresses. Each cell can have at most 238 LPTIDs for both unicast and multicast, but has a total class D IP multicast address space of 2.²⁸Contains the address. It is unlikely that a PACS microcell will have more than a dozen active PACS users, but each user can combine as many multicast groups as desired. This causes the PPC to handle more than 238 different multicast groups in each cell. In these situations, the m-LPTID must be reused and some multicast addresses may be mapped to a single m-LPTID. If this is the case, SU 102 reconstructs the datagram received over this m-LPTID and discards the datagram if it does not belong to the group to which SU 102 belongs.

【0064】

The mapping of IP multicast addresses to one or more PACS cell-wide group addresses per cell is stored in PFM 402's Multicast Address Mapping Table (MAMT) 514, which is accessed and managed by PFM 402. Multicast entries are instead stored with ART 404 unicast address mapping information. The MAMT 514 entry contains a list of (global multicast address G, RP cell number, m-LPTID, M LIST). Each multicast entry means that IP multicast address G has a corresponding PACS group with an m-LPTID assigned RP 104 in cell 112. The M LIST contains the network layer addresses (such as IP addresses) of all members of this group. The existence of an entry with cell number 1, m-LPTID = A, and global address G joins global multicast G, and there is at least one SU 102 in cell I where G's cell-wide group address is A. Means to do.

【0065】

When a multicast packet with address G is received by PFM 402 from PPN 416 and IP router 410, PFM 402 searches MAMT 514 for the entry with G. It provides cell identifiers for all RP 104s that have members that are members of Group G and the corresponding m-LPTID. If one entry is found, PFM 402 forwards the m-LPTID packet found from the entry to the corresponding cells 112 and PDCU 304. If a large number of entries are found (indicating that there are more cells with G members than 1), PFM 402 replicates the received packet with cell 122 found from the mapping in MAMT 514. Transfer one copy to each cell 122 via the associated PDCU 304. If no entry is found, PFM 402 simply drops the packet. This forwarding process is applied both when the packet comes from the network backbone (packet addressed to SU) and when the packet comes from SU (SU source packet). SU When 102 sends a multicast SU source packet, RP 104 receives it and forwards the packet through PDCU 304 to PFM 402. The PFM 402 then duplicates the packet if necessary and forwards it according to MAMT 514 to all cells that have members containing the cell 112 from which the packet originated.

【0066】

A in FIG. 14 and B in 14 are diagrams showing the multicast registration process. The PACS method is modified with a new type of PACS registration message (PACKET REG REQ) called "multicast registration". When the mobile PC first requests to join with IP multicast group G for ALT operation, SU first checks SU MAMT 516 to make sure there are no entries with IP multicast group G. To do. If it does not exist, SU 102 generates and sends a registration request message (PACKET REGREQ) containing the requested IP multicast address G and the terminal identifier of SU 102.

【0067】

PDCU 304 then authenticates the request and interacts with AM 108 to authorize the multicast service. Once authenticated, AM 108 responds with a reply that has a subscriber unit Internet Protocol (IP) address. PDCU 304 asks G's PFM 402 group matching module 522 to determine if the requested group G already exists in cell 112 of SU 102. This is because the requested group G is a new group in this cell, or the requested group G has already been combined by another member and a different registration behavior is required in each of these cases.

【0068】

If the requested group does not exist, the new m-LPTID will be assigned by PDCU 304 Assignment Module 520. A new m-LPTID is then sent to PFM 402, where it is assigned to the new multicast group by allocation module 524 and mapped to IP multicast address G by allocation module 520. The corresponding entry of the above information is then stored in MAMT514. As described here, the number of LPTIDs available for selection of each cell 112 is limited. The assigned m-LPTID can be selected from a group of LPTIDs reserved for multicast use. Instead, the m-LPTID can be selected from the LPTIDs available on a first-come, first-served basis. The LPTID can also be reused (shared between groups), which requires SU 102 to remove this unwanted message.

【0069】

If the requested group currently exists, G has an assigned m-LPTID and a corresponding entry exists. In this case, PFM 402 looks up the m-LPTID from ART 404 and adds the IP address of SU 102 to ART 404. In both cases, RPCU 106 returns the m-LPTID number of the (PACKET REG ACK) message to SU 102.

【0070】

As mentioned earlier, when SU 102 becomes a member of a multicast group, it will be assigned the m-LPTID of the group of interest. After receiving the m-LPTID for the group, the m-LPTID must be added to SU 102's SU Multicast Address Mapping Table (MAMT) 516. The SU MAMT516 does not have to be a replica of the MAMT514 in the RPCU 106, as the SU 102 only needs to keep track of the group it is bound to.

【0071】

The PACS multicast handoff involves two processes in the ALT. First, after SU 102 performs an ALT, it must rejoin all IP multicast groups it joins from the previous cell. That is because PACS multicast is cell-specific. Second, if this is an inter-RPCU ALT, the old RPCU 106 updates its MAMT 514 by removing this user from all the groups it is bound to.

【0072】

Explicit multicast deregistration is adopted to make effective use of wireless link bandwidth. A new type of deregistration, or "multicast deregistration," is created for multicast, as the current PACS standard method limits only one type of deregistration. The PACS user performs multicast deregistration only if it exits from a multicast that is still attached to the network, although it is joined in the same cell (ie not as a result of the ALT). If this user is permanently out of the network, SU 102 will perform regular deregistration, during which time RPCU 106 will remove SU 102 from all groups of MAMT 514.

【0073】

When the mobile PC requests to leave the IP multicast group, SU 102 sends a multicast deregistration message to notify RPCU 106. The multicast deregistration message contains the SU 102 IP address, the group address, and the m-LPTID mapped to this group address. During multicast deregistration, RPCU 106 checks if SU 102 is the only member of the multicast group. This is achieved by PFM 402, which searches for MAMT 514 for the corresponding m-LPTID and group address G. If so, RPCU 106 releases the m-LPTID and removes the corresponding pair from the corresponding entry in MAMT 514. Otherwise, PFM 402 removes only the IP address of SU 102 from MAMT 514.

【0074】

SU 102 does not need to perform deregistration when moving to a different cell 112. Due to the limited number of m-LPTIDs, if this were a member of a multicast group, the problem of removing SU 102 from the group users in cell 112 above would arise. This is handled by using the PACS mechanism that detects the inactivity of SU 102. When SU 102 does not send a message to RP 104 acting as cell 112 during the specified time period (maximum inactivity interval parameter), SU 102 raises and sends a packet with no data (PACKET NULL). To do. This can be done internally by instructions sent from SU 102 or RP 104. If there is no data arriving from SU 102 during the maximum inactivity period, SU 102 is expected to go offline or perform an ALT. In this case, the RPCU 106 handoff module directs the PFM 402 to remove the user from the corresponding entry in ART 404 (or MAMT 514).

【0075】

IP multicast uses the Group Membership Protocol (IGMP) to determine if subnet 418 has members for a particular group. Internet routers use this information to determine if traffic for a multicast group should be sent to subnet 418. In PISA 400, IP Router 410 sends a periodic IGMP membership inquiry message to the connecting link to RPCU 106, expecting at least one member to respond with the IGMP reporting message.

【0076】

Normally, IGMP query messages are multicast to all multicastable hosts on subnet 418. When one member responds, the response message is also multicast to the group, suppressing the response of the other members (because one response per group is sufficient). However, since the RPCU 106 already maintains the multicast mapping information in MAMT 514, using the same structure in PISA 400 creates unnecessary overhead. For each multicast address with one entry in MAMT 514, there must be at least one member in this RPCU 106 subnet 418. Therefore, RPCU 106 configures an IGMP support module (not shown) to receive all IGMP queries from IP router 410 and respond to IGMP reports generated by MAMT514. This PISA 400 group membership scheme seamlessly supports IGMP version 2. New multicast group is MAMT When attached to the 514, the RPCU sends an unsolicited membership report to the IP router 410, and when the multicast group is removed from the MAMT 514, the RPCU 106 sends an explicit message.

[Quality of service support] Quality of service (QoS) support for wireless networks is important but difficult to achieve. This is mainly due to the unpredictable nature of wireless link quality. However, different levels of service can be achieved with PACS by using different fragmentation schemes, packet scheduling (class-based queuing or weighted fair queuing) and ARQ. The purpose is to support multiple levels of service and fairness within each class of service by performing some packet drops and preferred delays over the downlink.

【0077】

PPC functionality is given a type of service (TOS) field as specified in each IP datagram. The field specifies the parameter type that is optimized when sending this datagram, such as minimum delay, maximum throughput, or maximum reliability. PDCU 304 detects each IP datagram header in the TOS field. Based on the TOS value, PDCU 304 makes the appropriate choice for IP transfer.

【0078】

The first choice is downlink fragmentation. Downlink DL packets must be split into DL fragments, and several methods can be used to do this. The usual case is "minimum fragmentation", in which fragmentation is always a multiple of 576 bytes (maximum fragment size). Minimal fragmentation produces the minimum number of fragments, which results in low overhead (fragmentation headers, etc.) and thus provides maximum processing power. Another method is "maximum fragmentation". Since each DL fragment can be sent in a separate slot, the DL packet may be split into eight smaller fragments for parallel transmission. The smaller the fragment, the faster the entire packet can arrive and the less delay is minimized.

【0079】

15 and 16 are diagrams showing aspects in which different fragmentation methods affect performance. The data is obtained by numerical analysis under ideal circumstances, all slots are cleared from the previous transmission, there are no errors in the wireless link, no retransmissions, no media access delay. Other PACS protocol overheads such as control messages, system information, confirmations, MACs, and superframe headers are also ignored.

【0080】

Figure 15 shows that the radio link propagation delay is a function of the IP packet size that constitutes the minimum delay. In the case of maximum fragmentation, packets are split approximately equally between 2, 4 or 8 slots (subject to PACS fragmentation rules).

【0081】

Figure 16 shows the normalized throughput (the size of the IP datagram divided by the overall coarse bandwidth) used to send the packet. The overhead is the framing overhead, which includes fragment and segment headers, DL and SL checksums, and padding to meet the minimum fragment size.

【0082】

These graphs show that the delay can be significantly reduced with an increase of less than 10 framing overhead. Therefore, it is feasible to manipulate the number of fragments in each service and send them in parallel in a large number of slots to achieve different levels of service. Nevertheless, the actual delay and packet loss are affected by load fluctuations, i.e. some slots have more segments in the column than others. Therefore, the fragmentation algorithm must take into account the length of the columns, so that alignment delay and packet loss do not affect the quality between terminals of service.

【0083】

Another structure that can be used to provide different levels of service on the downlink is ARQ. The PACS standard method allows PDCU 304 to selectively enable or disable the ACK of each DL packet 218. For example, for low drop priority IP datagrams, PDCU304 sets the DL packet header 220 to the "ACK required" bit. This allows SU 102 to approve all properly received segments and allow PDCU 304 to selectively retransmit missed or errored segments. This method will be further described below.

【0084】

Current PACS packet mode services specify two automatic repeat request (ARQ) schemes for error recovery at the PACS level. One of these schemes is used on the uplink (SU 102 to RP 104) and the other is used on the downlink (RP 104 to SU 102). As currently specified, uplink ARQs are absolute and downlink ARQs are packet-to-packet-based selective.

【0085】

PISA 400 modifies this architecture in two ways. First, in PISA 400, uplink ARQ is not absolute, but packet-to-packet-based selective. Second, ARQs are urged both uplink and downlink for loss-sensitive traffic (such as web traffic) and switched off for delay-sensitive traffic (such as Internet video and audio). This prevents wasting radio bandwidth by retransmitting packets that do not require error-free transmission over the PACS radio link, increasing effective capacity.

【0086】

As described above, the PFM 402 comprises a data payload analysis module 526. The data payload analysis module 526 determines whether the SU-addressed data payload is a loss-sensing message or a delay-sensing message. In one embodiment, this is done by deciding whether the SU-addressed data payload follows the Transmission Control Protocol (TCP), or whether it follows the User Datagram Protocol (UDP).

【0087】

In the downlink case, when PFM 402 inspects the destination IP address of a data packet, it also determines whether the packet's data payload follows TCP or UDP by looking at the IP packet header. If TCP and a matching entry are found in ART 404, PFM-PDCU interface module 528 tells the corresponding PDCU304 to set the required bit of ACK in DL header 220 to 1, and ARQ is SU 102. Indicates that it is needed from. If the data packet follows UDP, PFM-PDCU interface module 528 notifies the corresponding PDCU 304 to set the required bit of ACK in DL header 220 to 0, indicating that ARQ is not required.

【0088】

In the uplink case, the high layer 510 security layer of SU 102 sets the required bit of ACK to 0 or 1 based on whether the packet is TCP or UDP. When receiving a data packet with a required bit of ACK set to 0, PDCU 304 of RPCU 106 does not broadcast the transmit state of the downlink packet (otherwise required according to current PACS standards). ).

[Conclusion] This description concludes with a description of preferred embodiments of the present invention. In summary, the present invention describes methods and devices for multicasting data. The method of the present invention assigns a multicast packet terminal identifier to a multicast group when a cell subscriber device requests membership in the multicast group, receives a multicast packet with a global multicast address, and at least one multicast local packet. It has a step of determining the cell identifier from the mapping to the global multicast address to the terminal identifier and the cell identifier, and forwarding the multicast packet to the cell according to the cell identifier.

【0089】

The device of the present invention includes a radio port control device having a packet data control device, and the packet data control device is coupled to a radio port configured to receive a multicast packet and a packet transfer module. The packet data controller includes an allocation module configured to assign a multicast local packet terminal identifier to a multicast group when the cell subscriber device requests membership in the multicast group. The packet forwarding module is configured to determine the cell identifier from the mapping of at least one multicast local packet terminal identifier and the global multicast address of the multicast packet to the cell identifier. The packet forwarding module also forwards the multicast packet to the cell according to the cell identifier.

【0090】

The above description of preferred embodiments of the present invention has been made for purposes of illustration and explanation. The present invention is not intended to be limited to the exact forms disclosed. Numerous modifications and changes are possible in light of the above considerations.

【0091】

For example, although the above description focuses primarily on TDMA multi-cell networks for exemplary purposes, the principles of the present invention are Code Division Multiple Access (CDMA) and GSM systems (global systems for mobile communications), as well as future thirds. It can also be applied to 3rd generation mobile wireless networks.

【0092】

The technical scope of the present invention is not limited by this detailed description, but is intended to be limited by the description of the scope of claims. The detailed description, examples, and data described above provide a complete description of the manufacture and use of the configuration. Many embodiments of the invention can be made without departing from the technical scope of the invention, and the invention is defined by the claims.

[A brief description of the drawing] [Figure 1]

Schematic of a personal access communication system (PACS).

[Figure 2]

Structural diagram of PACS packet channel layer, PACS standard encapsulation and framing, and PACS TDM / TDMA radio link.

[Fig. 3]

Detailed view of encapsulated uplink and downlink messages.

[Fig. 4]

Detailed view of encapsulated uplink and downlink messages.

[Fig. 5]

Block diagram of the functional architecture of PPC.

[Fig. 6]

Schematic diagram of PACS Internet Service Architecture (AISA).

[Fig. 7]

Block diagram of one embodiment of a wireless port controller (RPCU).

[Fig. 8]

Block diagram of another embodiment of an RPCU using a commercial off-the-shelf IP router.

[Fig. 9]

The flowchart which showed the exemplary operation used in the practice of this invention.

[Fig. 10]

The flowchart which showed the exemplary operation used in the practice of this invention.

[Fig. 11]

Explanatory diagram of the operation showing registration and intra-RPCU handoff.

[Fig. 12]

Illustrated diagram of inter-RPCU handoff and deregistration operation.

[Fig. 13]

Illustrated diagram of message exchange during normal mobile IP registration and operation of PISA mobile IP registration.

[Fig. 14]

Explanatory drawing of operation of multicast registration in PISA.

[Fig. 15]

A characteristic diagram showing aspects that affect the performance of different fragmentation methods.

[Fig. 16]

A characteristic diagram showing aspects that affect the performance of different fragmentation methods.