1111111111111111 IIIIII IIIII 11111 1111111111 11111 lllll lllll lllll lllll 111111111111111 11111111
`US 20040085951Al
`
`(19) United States
`(12) Patent Application Publication
`Rezaiifar et al.
`
`(10) Pub. No.: US 2004/0085951 Al
`May 6, 2004
`(43) Pub. Date:
`
`(54) METHOD AND APPARATUS FOR THE USE
`OF MICRO-TUNNELS IN A
`COMMUNICATIONS SYSTEM
`
`(76)
`
`Inventors: Ramin Rezaiifar, San Diego, CA (US);
`Nikolai K.N. Leung, Takoma Park, MD
`(US); Paul E. Bender, San Diego, CA
`(US); Rajesh K. Pankaj, San Diego,
`CA(US)
`
`Correspondence Address:
`Qualcomm Incorporated
`Patents Department
`5775 Morehouse Drive
`San Diego, CA 92121-1714 (US)
`
`(21)
`
`Appl. No.:
`
`10/686,442
`
`(22)
`
`Filed:
`
`Oct. 14, 2003
`
`Related U.S. Application Data
`
`(60) Provisional application No. 60/418,815, filed on Oct.
`15, 2002.
`
`Publication Classification
`
`Int. Cl.7 ..................................................... H04L 12/66
`(51)
`(52) U.S. Cl. .............................................................. 370/352
`
`(57)
`
`ABSTRACT
`
`Micro-tunnels are used to provide multiple data service
`sessions to the same mobile node in a wireless communi(cid:173)
`cations system. Further, the flexibility of the micro-tunnels
`optimizes the resources of the system. On request for a data
`service, an encapsulation configuration record is generated.
`An encapsulation header is created in response to the
`encapsulation configuration. The encapsulation header
`includes a packet service identifier and a micro-tunnel
`identifier.
`
`100 ~
`
`PDSN
`
`102
`
`) C =)
`
`MN2
`
`(
`
`120 ~
`
`PCF/BSC
`
`104
`
`MSC
`114
`
`I
`
`~
`~
`
`\
`
`~
`~
`
`Microsoft
`Ex. 1006 - Page 1
`
`

`

`Patent Application Publication May 6, 2004 Sheet 1 of 3
`
`US 2004/0085951 Al
`
`Ovl
`
`en ,...
`~ ,...
`
`'
`
`(_)
`en
`ID
`u::
`(_)
`a..
`
`~I
`
`N z
`~
`
`n
`u
`
`r----.
`
`'-J
`
`z
`~
`
`r
`
`0
`,...
`C\J
`
`,... .
`C, -u.
`
`z
`en
`0
`a..
`
`~I
`
`r
`
`0
`
`0 ....
`
`Microsoft
`Ex. 1006 - Page 2
`
`

`

`Patent Application Publication May 6, 2004 Sheet 2 of 3
`
`US 2004/0085951 Al
`
`I-
`LU
`:::ii:::
`(.)
`
`<t: a..
`0
`<t:
`0
`
`....J >-<t: a..
`
`a:
`LU
`0
`<t:
`LU
`I
`LU a:
`
`(!)
`
`a:
`LU
`0
`<t:
`LU
`I
`
`>-a:
`LU >
`:J
`LU
`0
`
`(
`
`0
`0
`C\I
`
`~I
`
`~I
`
`~I
`
`C\I
`•
`C,
`
`-LL
`
`>-LU
`LU a:
`
`:::ii:::
`
`(!)
`
`gl
`
`0
`I-
`~
`
`gl
`
`C")
`•
`
`C, -LL
`
`gl
`
`CJ) a..
`
`w >-
`_J a:
`cc <t: (0
`<t: 0 0
`a:Z C")
`<t: :::> >g
`
`Microsoft
`Ex. 1006 - Page 3
`
`

`

`Patent Application Publication May 6, 2004 Sheet 3 of 3
`
`US 2004/0085951 Al
`
`Q)
`
`~ a.
`(J)
`,._
`Q)
`I+=
`:;::;
`C
`Q)
`"C
`
`--
`
`0
`
`z
`~
`
`C\I
`
`z
`~
`
`z
`~
`
`C\I
`
`z
`:E
`
`.
`(!J -LL
`
`----
`
`T""
`I
`
`~
`(\J
`
`Microsoft
`Ex. 1006 - Page 4
`
`

`

`US 2004/0085951 Al
`
`May 6, 2004
`
`1
`
`METHOD AND APPARATUS FOR THE USE OF
`MICRO-TUNNELS IN A COMMUNICATIONS
`SYSTEM
`[0001] The present Application for Patent claims priority
`to Provisional Application No. 60/418,815, entitled, "Micro(cid:173)
`Tunnels," filed Oct. 15, 2002, and assigned to the assignee
`hereof and hereby expressly incorporated by reference
`herein.
`
`routing until it arrives at the care-of address. Such encap(cid:173)
`sulation is also called tunneling, which suggests the packet
`burrows through the Internet, bypassing the usual effects of
`IP routing.
`[0010]
`In a mobile IP environment, there is a need to
`identify multiple tunnels each associated with a same mobile
`node. Further, there is a need for flexible tunnel set up which
`optimizes the resources of the system.
`
`BACKGROUND
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0002] 1. Field
`[0003] The present invention relates generally to data
`packet transmission and specifically to the use of micro(cid:173)
`tunnels.
`[0004] 2. Background
`[0005]
`Internet Protocol (IP) "tunnels" have become a
`widespread mechanism to transport data units, referred to as
`datagrams, over the Internet. Using Tunneling involves
`incorporating an original IP packet inside of another IP
`packet. Tunneling also has additional connotations about
`changing the effects of Internet routing on the original IP
`packet.
`[0006] Typically, a tunnel is used to augment and modify
`the behavior of the deployed routing architecture, such as in
`multicast routing, mobile IP, and Virtual Private Network
`(VPN). From the perspective of traditional best-effort IP
`packet delivery, a tunnel behaves as any other link. Packets
`enter one end of the tunnel, and are delivered to the other end
`unless resource overload or error causes them to be lost.
`[0007]
`Information may be encapsulated and routed
`through a tunnel. In the most general case, a system has a
`packet, which is referred to as a payload packet, which needs
`to be encapsulated and routed. The payload packet is first
`encapsulated in a Generic Routing Encapsulation (GRE)
`packet, which possibly also includes a routing. The resulting
`GRE packet may then be encapsulated in some other pro(cid:173)
`tocol and then forwarded. This outer protocol is referred to
`as the delivery protocol.
`[0008] For mobile IP, a wireless system interfaces with an
`IP network. Tunnels are used for transporting data from the
`IP network to infrastructure elements in the wireless system.
`The data may involve multiple streams of data for transmis(cid:173)
`sion to and/or from a same mobile node. In this case, the
`system must establish individual tunnels for each stream.
`[0009]
`In mobile IP the home agent associated with the
`mobile node redirects packets from the home network to the
`care-of address by constructing a new IP header containing
`the mobile node's care-of address as the destination IP
`address. The home agent is a router on a mobile node's home
`network maintaining information about the device's current
`location, as identified in its care-of address. The care-of
`address is a temporary IP address for a mobile node enabling
`message delivery when the device is connecting from some(cid:173)
`where other than its home network. The care-of address
`identifies a mobile node's current point of attachment to the
`Internet and makes it possible to connect from a different
`location without changing the device's home address (per(cid:173)
`manent IP address). The new header then shields or encap(cid:173)
`sulates the original packet, causing the mobile node's home
`address to have no effect on the encapsulated packet's
`
`[0011] FIG. 1 is a wireless communication system sup(cid:173)
`porting mobile IP.
`[0012] FIG. 2 is a Generic Routing Encapsulation (GRE)
`format.
`[0013] FIG. 3 is a GRE key format.
`[0014] FIG. 4 is an illustration of the GRE key space.
`
`DETAILED DESCRIPTION
`
`[0015] The field of wireless communications has many
`applications including, e.g., cordless telephones, paging,
`wireless local loops, Personal Digital Assistants (PDAs),
`Internet telephony, and satellite communication systems. A
`particularly important application is cellular telephone sys(cid:173)
`tems for mobile subscribers. As used herein, the term
`"cellular" system encompasses both cellular and Personal
`Communication Services (PCS) frequencies. Various over(cid:173)
`the-air interfaces have been developed for such cellular
`telephone systems including, e.g., Frequency Division Mul(cid:173)
`tiple Access (FDMA), Time Division Multiple Access
`(TDMA), and Code Division Multiple Access (CDMA). In
`connection therewith, various domestic and international
`standards have been established including, e.g., Advanced
`Mobile Phone Service (AMPS), Global System for Mobile
`(GSM), and Interim Standard 95 (IS-95). IS-95 and its
`derivatives, IS-95A, IS-95B, ANSI J-STD-008 (often
`referred to collectively herein as IS-95), and proposed
`high-data-rate systems are promulgated by the Telecommu(cid:173)
`nication Industry Association (TIA) and other well known
`standards bodies.
`[0016] Cellular telephone systems configured in accor(cid:173)
`dance with the use of the IS-95 standard employ CDMA
`signal processing techniques to provide highly efficient and
`robust cellular telephone service. An exemplary system
`utilizing CDMA techniques is the cdma2000 ITU-R Radio
`Transmission Technology (RTT) Candidate Submission
`(referred to herein as cdma2000), issued by the TIA The
`standard for cdma2000 is given in the draft versions of
`IS-2000 and has been approved by the TIA and 3GPP2.
`[0017] Another CDMA standard is the W-CDMA stan(cid:173)
`dard, as embodied in 3'd Generation Partnership Project
`"3GPP," Document Nos. 3G TS 25.211, 3G TS 25.212, 3G
`TS 25.213, and 3G TS 25.214.
`[0018] A cellular communication system supporting
`mobile IP is illustrated in FIG. 1.
`[0019] System 100 supports communications of packets of
`data, wherein a packet is a logical grouping of information
`including a header containing control information and user
`data. Packets most often are used to refer to network layer
`units of data. Note the terms datagram, frame, message, and
`
`Microsoft
`Ex. 1006 - Page 5
`
`

`

`US 2004/0085951 Al
`
`May 6, 2004
`
`2
`
`segment also are used to describe logical information group(cid:173)
`ings at various layers of the Open Systems Interconnection
`(OSI) reference model.
`
`In the system 100, a Packet Data Service Node
`[0020]
`(PDSN) 102 interfaces between the wireless communication
`system and an IP network. In the mobile IP environment, the
`PDSN may also be referred to as a Foreign Agent (FA). The
`Home Agent (HA) is the node in the home network of the
`mobile node effectively causing the mobile node to be
`reachable at a home address even when the mobile node is
`not attached to the home network.
`
`[0021] Continuing with FIG. 1, the PDSN 102 commu(cid:173)
`nicates with the various Mobile Nodes (MNs) via a Packet
`Control Function/Base Station Controller (PCF/BSC) 104.
`
`[0022] Note the PCF and BSC may reside in separate
`infrastructure elements or may be combined in one element
`as illustrated in FIG. 1. The PDSN 102 provides commu(cid:173)
`nications for MN 108, 110 via the PCF/BSC 104. A Mobile
`Switching Center (MSC) is also in communication with
`PCF/BSC 104.
`
`[0023] For a typical packet data communication, the PCF/
`BSC 104 sends an All-Registration Request message to the
`PDSN 102 to establish an Al0/11 interface between itself
`and the PDSN. The various interfaces refer to the commu(cid:173)
`nication links or sessions between the infrastructure ele(cid:173)
`ments. The All interface is generally identified as the link
`between the PDSN 102 and the PCF/BSC 104.
`
`[0024] The PCF/BSC 104 binds the mobile station iden(cid:173)
`tifier, e.g. a Mobile Identification Number (MIN) such as an
`International Mobile Subscriber Identity (IMSI), to a Packet
`Session Identifier (PSI) unique within the PCF/BSC 104.
`The IMSI is a number used to uniquely identify personal
`mobile stations (i.e., mobile nodes). In some cases, ambi(cid:173)
`guity might arise when using only the 10-digit MIN. In one
`system, the first three (most significant) decimal numbers of
`the IMSI are the Mobile Country Code (MCC); the remain(cid:173)
`ing digits are the National Mobile Station Identity (NMSI).
`
`[0025] For each data communication to MN 108 or MN
`110, the PCF/BSC 104 establishes a separate link. When the
`PCF/BSC 104 establishes the link, the PCF/BSC 104
`includes the PSI in the All-Registration-Request message
`that is sent to the PDSN. In this way, a communication
`intended for a given MN, such as MN 108 or MN 110, is
`processed via the designated link. As the number of data
`services increases, a MN may desire to have multiple data
`communications concurrently. In this case, the PCF/BSC
`104 seeks to establish a link for each communication.
`
`[0026] As described herein "micro-tunnels" are logical
`connections between the PDSN 102 and the PCF/BSC 104
`that are identified by a source IP address and a destination
`IP address. For example, the source IP address may be
`identified as "src _ip _ address," and the destination IP address
`may be identified as "dest_ip_address." A micro-tunnel is
`then designated by the following:
`
`[0027] <src _ip _ address=PDSN _IP, dest_ip _ address=
`PCF_IP, GRE_key>.
`
`In this context, the source refers to the PDSN 102,
`[0028]
`the destination refers to the PCF/BSC 104. Note, micro(cid:173)
`tunnels are independent of the air-interface service instances
`
`(i.e., no one-to-one mapping is assumed between the micro(cid:173)
`tunnels and the air-interface service instances).
`
`[0029] Each micro-tunnel is assigned a separate commu(cid:173)
`nication for a given MN. As illustrated in FIG. 1, multiple
`micro-tunnels may be established for one MN. In the
`example of FIG. 1, three micro-tunnels are established for
`three separate communications to MN 108, while two
`micro-tunnels are established for two separate communica(cid:173)
`tions to MN 110. However, a single communication may
`utilize one or more micro-tunnels. The micro-tunnels are
`established when the PCF/BSC 104 sends a message to the
`PDSN 102. Specifically, the message is an All-Registration(cid:173)
`Request.
`
`[0030] Once a micro-tunnel is established, a communica(cid:173)
`tion may be transmitted via the established micro-tunnel.
`There is not necessarily a one-to-one mapping between the
`air-interface service instances and micro-tunnels.
`
`[0031] The micro-tunnel serves the following purposes:
`
`[0032]
`
`Identify the PPP context;
`
`[0033]
`
`Identify the IP context; and
`
`[0034] Differentiate services.
`
`[0035] The following discussion details each of these
`micro-tunnel functions.
`
`[0036] PPP Context:
`
`[0037] The micro-tunnels are used by the PDSN 102 to
`indicate to the Radio Access Network (RAN) 120 whether
`the data packets carried by the micro-tunnel may be dropped
`or not. In lieu of such indication, the RAN 120 may decide
`to drop packets if they get too stale. For example, if stateful
`compression or encryption is used, dropping packets in the
`RAN 120 may cause problems for de-compression. State is
`a collection of information maintained by an entity. Stateful
`encryption or compression means the encryptor/decryptor or
`the compressor/decompressor maintains state information.
`Dropped packets therefore will impact the compressor/
`decompressor processes. In such a case, the PDSN 102
`selects a "do not drop" attribute for the micro-tunnel.
`
`[0038] The micro-tunnels are further used by the PDSN
`102 to indicate those packets transported via a given micro(cid:173)
`tunnel are to be treated differently from the other packets
`transported via another micro-tunnel. For example, the
`PDSN 102 may indicate packets carried by a first micro(cid:173)
`tunnel have a particular header compression, such as zero(cid:173)
`byte-header compression. The PCF/BSC 104 then interprets
`this information and uses a Radio Link Protocol (RLP)-free
`service instance to carry these packets.
`
`[0039]
`
`IP Context:
`
`[0040] Using micro-tunnels the PDSN 102 indicates to the
`RAN 120 that re-ordering of data packets is allowed across
`micro-tunnels but not within
`the micro-tunnels. This
`approach is consistent with recommendations in section 4.1
`of "Differentiated Services and Tunnels" by D. Black,
`published October 2000, and identified as RFC 2983 by the
`Internet Engineering Task Force (IETF). In some situations,
`it may be desirable to enable reordering among packets in
`different micro-tunnels to coexist with an absence of packet
`reordering within each individual micro-tunnel.
`
`Microsoft
`Ex. 1006 - Page 6
`
`

`

`US 2004/0085951 Al
`
`May 6, 2004
`
`3
`
`[0041]
`In a first scenario, a node supporting various qual(cid:173)
`ity of service requirements and discriminate among packets,
`such as a Differentiated Services (DS) node, is instructed not
`to re-order packets belonging to the same micro-flow and the
`same quality of service requirements, such as an Assured
`Forwarding (AF) class. Note, DS and AF classes are defined
`in: (1) "Assured Forwarding PHB Group" by J. Heinanen et
`al., published June 1999 and identified as RFC 2597; (2)
`"Definition of the Differentiated Services Field (DS Field) in
`the IPv4 and IPv6 Headers" by K. Nichols, published
`December 1998, and identified as RFC 2474; and (3) "An
`Architecture for Differentiated Services" by S. Blake, pub(cid:173)
`lished December 1998, and identified as RFC 2475. Each of
`the RFC documents referenced herein is provided by the
`Network Working Group of the Internet Engineering Task
`Force (IETF).
`[0042] Differentiated Services (DS) are intended to pro(cid:173)
`vide a framework and building blocks to enable deployment
`of scalable service discrimination in the Internet. The dif(cid:173)
`ferentiated services approach aims to speed deployment by
`separating the architecture into two major components, one
`of which is fairly well-understood and the other of which is
`just beginning to be understood. Packet forwarding is a task
`which is performed on a per-packet basis as quickly as
`possible. Forwarding uses the packet header to find an entry
`in a routing table specifying the packet's output interface.
`Routing sets the entries in the table and may need to reflect
`a range of transit and other policies as well as to keep track
`of route failures. Routing tables are maintained as a back(cid:173)
`ground process to the forwarding task. A Differentiated
`Services Domain is a contiguous portion of the Internet over
`which a consistent set of differentiated services policies are
`administered in a coordinated fashion. A differentiated ser(cid:173)
`vices domain may
`represent different administrative
`domains or autonomous systems, different trust regions,
`different network technologies (e.g., cell/frame), hosts and
`routers, etc.
`[0043] Alternate embodiments may apply alternate meth(cid:173)
`ods whereby packets are discriminated among and unique
`treatment applied thereto. Alternate services also provide
`quality of service variations to different data packets.
`[0044] Assured Forwarding of IP packets over the Internet
`is desirable, for example, when a company uses the Internet
`to interconnect to geographically distributed sites and wants
`an assurance that IP packets within this intranet are for(cid:173)
`warded with high probability. In this situation, it is desirable
`for the network to not reorder packets belonging to the same
`microflow, wherein a microflow: is a single instance of an
`application-to-application flow of packets which is identi(cid:173)
`fied by source address, destination address, protocol id, and
`source port, destination port (where applicable).
`[0045] Assured Forwarding (AF) grouping provides a
`means for a provider DS domain to offer different levels of
`forwarding assurances for IP packets received from a cus(cid:173)
`tomer DS domain. Four AF classes are defined, wherein
`each AF class is, in each DS node, allocated a certain amount
`of forwarding resources, such as buffer space and band(cid:173)
`width. IP packets wishing to use the services provided by the
`AF group are assigned by the customer or the provider DS
`domain into one or more of these AF classes according to the
`services to which the customer has subscribed.
`[0046] Within each AF class, IP packets are marked with
`one of three possible drop precedence values. In case of
`
`congestion, the drop precedence of a packet determines the
`relative importance of the packet within the AF class. A
`congested DS node tries to protect packets with a lower drop
`precedence value from being lost by preferably discarding
`packets with a higher drop precedence value.
`[0047]
`In a DS node, the level of forwarding assurance of
`an IP packet thus depends on: (1) the amount of forwarding
`resources allocated to the AF class to which the packet
`belongs, (2) the current load of the AF class, and, in case of
`congestion within the class, (3) the drop precedence of the
`packet.
`[0048] For example, if traffic conditioning actions at the
`ingress of the provider DS domain make sure an AF class in
`the DS nodes is only moderately loaded by packets with the
`lowest drop precedence value and is not overloaded by
`packets with the two lowest drop precedence values, then the
`AF class may offer a high level of forwarding assurance.
`[0049]
`In another embodiment, the Assured Forwarding
`(AF) group provides forwarding of IP packets in N inde(cid:173)
`pendent AF classes. Within each AF class, an IP packet is
`assigned one of M different levels of drop precedence. An IP
`packet belonging to an AF class i and has drop precedence
`j is marked with the AF codepoint AFij, where 1 <=i<=N and
`l<=j<=M. Currently, four classes (N=4) with three levels of
`drop precedence in each class (M=3) are defined for general
`use. More AF classes or levels of drop precedence may be
`defined for local use.
`[0050] The identity of the micro-flow is hidden (due to
`GRE encapsulation) on the R-P interface between the RAN
`and the PDSN. Therefore, the DS nodes between the PDSN
`and RAN cannot distinguish different micro-flows from each
`other unless the PDSN uses a micro-tunnel for each micro(cid:173)
`flow in order to satisfy the in-sequence delivery require(cid:173)
`ment. Another example of the flows which are sensitive to
`re-ordering is flows protected by IPsec.
`[0051] The GRE format is illustrated in FIG. 2. The data
`packet format includes a delivery header 202, a GRE header
`204 and a payload packet 206. The GRE header 204 may
`include a key field containing a four octet number which was
`inserted by the encapsulator. The key may be used by the
`receiver to authenticate the source of the packet. In one
`embodiment, the key field is made up of two fields. Also, the
`GRE header 204 may include a sequence number field. The
`sequence number field contains an unsigned 32 bit integer
`which is inserted by an encapsulator. It may be used by the
`receiver to establish the order in which packets have been
`transmitted from the encapsulator to the receiver.
`[0052]
`In another scenario, certain packets, such as Layer
`2 Tunneling Protocol (L2TP) packets and IPsec packets,
`should not be re-ordered. By using a separate micro-tunnel
`for these types of traffic, the PDSN 102 instructs the
`PCF/BSC 104 that re-ordering is allowed among the IPsec/
`L2TP traffic, but not within a micro-tunnel. Note, L2TP is an
`industry-standard Internet tunneling protocol. Unlike Point(cid:173)
`to-Point Tunneling Protocol (PPTP), L2TP does not require
`IP connectivity between the client workstation and the
`server. L2TP requires only that the tunnel medium provide
`packet-oriented point-to-point connectivity. The protocol
`may be used over media such as ATM, Frame Relay, and
`X.25. L2TP provides the same functionality as PPTP. Based
`on Layer 2 Forwarding (L2F) and PPTP specifications,
`L2TP allows clients to set up tunnels across intervening
`networks.
`
`Microsoft
`Ex. 1006 - Page 7
`
`

`

`US 2004/0085951 Al
`
`May 6, 2004
`
`4
`
`[0053]
`In another aspect, for different micro-tunnels, the
`sequence space for the sequence field of the GRE header 204
`is different. If all the micro-tunnels share the same sequence
`space, then the R-P interface may not able to take advantage
`of treating the Differentiated Services Code Point (DSCP)
`marking differently. DSCP is used for implemented Quality
`of Service (QoS). A replacement header field, called the DS
`field, includes six bits of as a DSCP codepoint, to select the
`per-hop-behavior a packet experiences at each node. The
`DSCP is detailed in RFC 2474, described hereinabove.
`[0054] The receiver would re-order the packets based on
`the GRE sequence number and any gain which could have
`been achieved by the R-P interface giving packets with
`certain code-point a higher priority would be lost. If different
`micro-tunnels do not share the same sequence space, the
`PDSN may use a different micro-tunnel for sending packets
`with different DSCP.
`[0055] Service differentiation for the traffic carried by
`each micro-tunnel is independent of the micro-tunnel ID and
`is based on the outer DSCP or other signaling information
`exchanged between the PDSN and RAN (e.g., RSVP).
`[0056] Format of the GRE key field:
`[0057] FIG. 3 illustrates the GRE key field 300 of the
`GRE header 204 according to one embodiment, wherein the
`GRE key field 300 includes two fields: Packet Service
`Identifier (PSI) 302; and Micro-Tunnel Identifier (MTID)
`304. The boundary 306 between the two fields is not fixed,
`and therefore is illustrated to indicate the boundary may be
`adjusted or determined by the PCF/BSC 104 or the PDSN
`102. The GRE key field 300 is used by the PDSN 102 to
`identify the micro-tunnel for a given user by the MTID, as
`well as identifying the associated MN by the PSI.
`[0058] To build the GRE key field 300, the PCF/BSC 104
`receives a request for a data service from a MN, such as MN
`108. The PCF/BSC 104 requests the establishment of a link
`for servicing the data service for MN 108. The PCF/BSC
`108 sends a GRE key configuration record to the PDSN 104.
`The GRE key configuration record may be provided in the
`form <PSI,L>, wherein L indicates the length of the MTID
`field 304.
`
`[0059] For example, for if the record is given as <00,2>,
`the PSI is identified by digital value 00 and the last two bits
`are available for identifying the MTID. Each value of the
`GRE key field in the GRE tunnel between the PDSN 102 and
`the PCF/BSC 104 identifies a micro-tunnel. For the PSI field
`determination, the PCF/BSC 104 structures a list of <net(cid:173)
`work address, subnet mask>pairs from which the PCF
`chooses to associate a mobile node.
`
`[0060] A general scheme for constructing the GRE key
`field 300 allows the PCF to determine the available PSI
`values for a given mobile node. In other words, the PCF
`determines the GRE key configuration record. In one
`embodiment, the GRE key field 300 is specified as having a
`fixed number of bits, i.e., a fixed length. For example, the
`GRE key field 300 may be specified as 32 bits defining a
`GRE key space as illustrated in FIG. 4. Each value in the
`GRE key space is identified by four bits. The GRE key field
`300 is used to identify both the PSI field 302 and the MTID
`field 304 as illustrated in FIG. 3. Therefore, if two bits are
`used to identify the MN, i.e., the destination identifier PSI,
`there are two bits left to identify the micro-tunnel, i.e., for
`
`the micro-tunnel identifier MTID. In this way, the PCF is
`able to allocate the total available values in the GRE key
`space to multiple mobile nodes.
`
`[0061] As an example, the PCF may assign the two MSB
`bits 00 to MN 108. The configuration record would be
`<00,2>indicating that 2 bits remain for micro-tunnel iden(cid:173)
`tifiers, i.e., MTID. The corresponding to GRE key values
`available for MN 108 are then 0000, 0001, 0010, and 0011.
`The MN 108 would have 4 available identifiers for micro(cid:173)
`tunnels. The PCF may then assign the three MSB bits 010 to
`MN 110, wherein the configuration record would be <010,
`l>indicating there is one bit left for the MTID. In this case,
`MN 110 would have 2 identifiers available for micro(cid:173)
`tunnels. The resultant GRE key values available for MN 110
`would be 0100, 0101. In other words, the boundary 306
`between the PSI field 302 and the MTID field 304 is variable
`per mobile node. The ability to craft the PSI and MTID fields
`302, 304 available for different mobile nodes may result in
`a GRE key space which is fragmented. The fragmentation
`provides flexibility in resource allocation within the system.
`As described hereinabove, the PCF determines the assign(cid:173)
`ments within the GRE key space and provides this infor(cid:173)
`mation to the PDSN in the form of a configuration record.
`
`[0062]
`It is desirable to allocate the available identifiers
`for multiple mobile nodes, and therefore, the PCF deter(cid:173)
`mines a range of values for each mobile node. Such deter(cid:173)
`mination may be based on historical usage of mobile nodes,
`available services, or some other design criteria specific to
`the system. While the GRE key field 300 is specified as a
`fixed length, the PSI and MTID fields 302, 304 have variable
`length, as indicated by the variable boundary 306. The
`longer the PSI field 302, i.e., more bits allocated to PSI, the
`more mobile nodes may be identified, as the PSI is used to
`identify the mobile node. The longer PSI fields, however,
`leave fewer bits for the MTID, which identifies each of the
`micro-tunnels for a given mobile node, and therefore, the
`fewer micro-tunnels available per mobile node. Similarly,
`shorter PSI fields allow fewer MNs, but allow more micro(cid:173)
`tunnels per MN.
`
`[0063] Note, alternate embodiments may utilize an alter(cid:173)
`nate field having a different number of bits than the GRE key
`field 300. Still other embodiments may implement a field
`having a variable number of bits, the PSI and MTID fields
`302, 304 are then allocated within the variable length field.
`In these latter embodiments, the PSI and MTID length
`allocation may be determined proportionally, or may be
`specifically determined given the current length of the
`variable length field.
`
`[0064] When the PDSN 102 receives traffic destined for
`the PPP instance associated with a particular mobile node,
`the PDSN 102 encapsulates the traffic in a GRE tunnel and
`sets the GRE key field 300 as described herein. The PDSN
`102 sets the Most Significant Bits (MSBs) of the GRE key
`field 300 (i.e., PSI field 302) to the one of the network
`addresses which the PCF/BSC 104 has advertised in the
`All-Registration-Request message for a particular MN,
`wherein each PPP instance is associated with an IMSI. The
`length of the network address is determined by the subnet
`mask associated with the network address used.
`
`[0065] The PDSN 102 sets the LSBs of the GRE key field
`300 (i.e., MTID field 304) to identify the micro-tunnel in
`
`Microsoft
`Ex. 1006 - Page 8
`
`

`

`US 2004/0085951 Al
`
`May 6, 2004
`
`5
`
`which the packet should be carried. The numerical value of
`the LSBs has no significance and is only used to identify a
`micro-tunnel.
`
`[0066] The PCF/BSC 104 routes packets received via
`micro-tunnels to the mobile stations by examining the GRE
`key field 300 of the GRE header 204 and determining the
`associated mobile station ID based on the "routing tables"
`advertised to the PDSN in the All-Registration-Request
`message. In one case, the PCF/BSC 102 may specify the
`MSBs of the GRE key field 300 and allow the PDSN 104 to
`specify the LSBs of the GRE key field 300.
`
`[0067]
`In order to make the All-Registration Message
`backwards compatible, the PCF/BSC 104 may populate the
`PSI field in the All-Registration Request with the PSI field
`which is left-justified and append the length of the PSI field
`as a new information element to the All-Registration
`Request message.
`
`[0068] An alternative method of specifying the GRE Key
`associated with micro-tunnels is where the BSC/PCF sends
`to the PDSN (in an All-Registration Request message) the
`entire 32-bits of the GRE Key for the micro-tunnel along
`with the QoS characteristics of the micro-tunnel to be
`established.
`
`[0069] The PDSN 102 is the entity to drop packets if
`congestion occurs at the RAN 120, which is where a
`bottleneck may be expected. Note that the PDSN 102 is the
`entity which may drop a whole IP packet without the need
`to remove the link layer framing (the BSC gets the packets
`when HDLC is already applied to them). Also, the PDSN
`102 distinguishes a PPP control packet from a PPP frame
`containing data (again the PCF/BSC 102 has to peek into the
`packet in order to make this distinction). The RAN is where
`the queues associated with packets with different QoS
`requirements are formed.
`
`[0070] Because of the above facts, the PCF/BSC 104 may
`be the entity which provides back-pressure to the PDSN 102.
`The PCF/BSC 104 should apply back-pressure based on the
`DS code points. The idea is that the length of the PCF/BSC
`104 queues for different DSCPs may be different because the
`PCF/BSC services the bins for different DSCPs differently.
`More precisely, the PCF should be able to apply back(cid:173)
`pressure by specifying <PSI, DSCP, MTID> triplet. The
`mobile should be able to set any of the PSI, DSCP, or MTID
`to a wild-card value. For example, a <PSI, *, *> indicates a
`back-pressure for all the traffic destined for the mobile
`identified by the PSI.
`
`[0071] The current A-interface signaling maps each air
`interface service instance identified by an sr _id to a GRE
`tunnel identified by <src _ip=PDSN _IP, dest_ip=PCF _IP,
`GRE _ key=PSI>. It is also expected for the PDSN to map the
`received packets from the Internet side to an appropriate
`air-interface pipe which is identified by the sr _id. In the
`method, the following assumptions are made: (1) the air(cid:173)
`inter