KR20090008449A - Wireless communication method and system for activating multiple service bearers via efficient packet data protocol context activation procedures - Google Patents

Abstract

A method and apparatus for executing attachment procedures in a long term evolution (LTE) system to accommodate a single tunnel approach. Third Generation Partnership Program (3GPP) packet data protocol (PDP) context activation procedures are used for the allocation of an Internet protocol (IP) address and the establishment of tunneling between an evolved Node-B (eNodeB) and an anchor node, while allowing multiple radio access bearers (RABs) to be mapped to one PDP context for different quality of service (QoS) requirements. Thus, one PDP context is sufficient for a wireless transmit/receive unit (WTRU) within a single packet data network (PDN). Multiple PDP contexts can be established for special requirements, (e.g., bundled services), or when the WTRU connects to multiple PDNs.

Description

WIRELESS COMMUNICATION METHOD AND SYSTEM FOR ACTIVATING MULTIPLE SERVICE BEARERS VIA EFFICIENT PACKET DATA PROTOCOL CONTEXT ACTIVATION PROCEDURES}

The present invention relates generally to wireless communication systems. More specifically, the present invention relates to a single secondary packet data protocol in third generation partnership project (3GPP) systems (ie, generic packet radio service (GPRS) and universal mobile telecommunication systems), long term evolution (LTE) systems. A method and apparatus for activating a plurality of service bearers using a (PDP) context activation procedure. The procedure may be implemented in a GPRS dual tunnel approach and a direct tunnel approach in GPRS and LTE systems.

Traditionally, cellular networks have been designed for voice services only. GPRS supports some types of data services, such as text messaging and email. However, more data services and multimedia services are being introduced as applications operating on cellular networks such as Voice over Internet Protocol (VoIP), Internet Protocol (IP) Television (IPTV), and the like. Cell phones are transitioning from voice service phones to centralized data centers, and cellular networks are advancing toward all next-generation IP networks and packet services with an IP multimedia subsystem (IMS) infrastructure. In addition to the need for higher data rates, cellular networks also need to support IP applications and packet switched (PS) services more efficiently (i.e. due to the large number of configuration procedures at various nodes in the network). Architecture switching (needed to reduce latency and reduce latency in service data traffic due to excessive processing).

1 through 3 illustrate a wireless transmit / receive unit (WTRU) 105, a radio access network (RAN) 110, a serving general packet radio service (GPRS) support node (SGSN) 115, and a gateway GPRS support node (GGSN). Signaling in a typical wireless communication system 100 that includes 120 is shown. One Packet Data Protocol (PDP) context is associated with one Radio Access Bearer (RAB) for 3GPP PS service. Thus, to support multiple services, one primary PDP context activation procedure and multiple secondary PDP context activation procedures are described in 3GPP Technical Specification (TS) 23.060, as shown in FIGS. It is necessary to enable these services. For example, a data subscriber who wants to access IMS-based services (ie, VoIP, multimedia, etc.) while simultaneously activating web browsing, email service, fax service, etc., performs a separate PDP context activation for each service. Should be. Until all services are operational, the subscriber can wait a significant amount of time, just as it would wait to boot the computer.

In today's 3GPP PS service, one PDP context is associated with one RAB. Thus, to support multiple services, as shown in FIGS. 1 and 2, one primary PDP context and multiple secondary PDP contexts need to be activated. In addition, in order to support IMS services, a primary PDP context for session initiation protocol (SIP) signaling and a secondary PDP context for each data service need always be (enabled).

The present invention provides a method and apparatus for reducing processing delay in data traffic services due to excessive configuration and service establishment delays due to multiple consecutive configuration procedures at various nodes in a network (eg, GPRS, UMTS). And LTE system. The present invention proposes a simplified secondary PDP context activation procedure that activates multiple services in a single step. The present invention reuses current 3GPP PDP context activation procedures for allocating IP addresses, initiating services, and establishing tunneling between various components in the network (ie, RAN, SGSN, GGSN, IMS, etc.). The present invention allows for the activation of multiple PDP contexts using a single step secondary PDP context activation in which each service is associated with any service bearer in the core network (CN) and a specific RAB in the RAN. The present invention also enables the establishment of multiple RABs that map to one PDP context for different QoS requirements. Such multiple PDP contexts may be established for special requirements (eg, bundled services) or may be established when a WTRU connects to multiple PDNs.

The present invention reduces delays in secondary PDP context activation and delays due to any change in secondary PDP context activation when more services are needed. For example, if a personal data assistant (PDA) terminal is run, the user configures the PDA terminal to activate VoIP services, video conferencing, email accounts, and the like. According to the procedures in current TS 23.060, the WTRU performs each procedure individually and sequentially. The present invention reduces unnecessary steps used in the secondary PDP context activation procedure. The WTRU requests additional bearers by sending a request to the RAN (eg, eNodeB), and the RAN requests the request to see if the additional bearer can fit within the allocated resources of the current PDP context (ie, bearer). Investigate If additional bearers are added, eNodeB sends the request to the mobility management entity (MME) for further investigation.

The service type of the request determines whether a secondary PDP context is needed. A secondary PDP context is needed if the requested service is provided by different PDNs at different anchor nodes. If the same PDN and anchor node provide the requested service, the MME sends a service request to the anchor node, assigning the new service bearer a mapping of the required resources and network layer service access point identifiers (NSAPI) requested by the WTRU. do. In this process, the anchor node is informed by the tunnel endpoint identifier (TEID) of the supporting eNodeB. After receiving the acknowledgment, the MME establishes the other end of the tunnel by sending a RAB establishment request to eNodeB, which is updated with the anchor node TEID. The MME then requests that the WTRU update its RAB resources. The WTRU then responds to the eNodeB with a completion notification, which in turn informs the MME that the process has completed successfully. If an error or counter timeout occurs in the MME, the MME proceeds to release the previously allocated tunnels and resources.

The invention is advantageous compared to the prior art for the following reasons: 1) several bearers are allocated in the primary PDP context; 2) single tunnel establishment versus 3GPP (GPRS) two tunnels (new architecture); And 3) a reduced number of steps (combination of secondary PDP activation and RAB establishment request).

A more detailed understanding of the invention may be obtained from the description of the preferred embodiments below, given by way of example with reference to the accompanying drawings. Brief description of the accompanying drawings is as follows:

1 illustrates a typical primary PDP context activation procedure for lu mode in a conventional wireless communication system.

2 shows a typical secondary PDP context activation procedure for lu mode in a conventional wireless communication system.

3 shows a flowchart of a typical PDP context activation procedure in a conventional wireless communication system.

4 is a signal flow diagram of a PDP context activation procedure in the LTE system according to an embodiment of the present invention.

5 is a signal flow diagram of a PDP context activation procedure in the LTE system according to another embodiment of the present invention.

6 illustrates the establishment of multiple PDP contexts for multiple PDNs.

In the following, the term "wireless transmit / receive unit (WTRU)" includes user equipment (UE), mobile station, fixed subscriber unit or mobile subscriber unit, pager, cellular phone, personal digital assistant (PDA), computer, or wireless environment. Any type of user device capable of operating in, but is not limited to, these examples. In the following description, the term "base station" includes, but is not limited to, a Node B, a site controller, an access point (AP), or any type of interfacing device capable of operating in a wireless environment.

In accordance with an embodiment of the present invention, FIG. 4 illustrates PDP context activation and RAB allocation in LTE system 400 including WTRU 405, eNodeB 410, MME 415, and anchor node 420. The procedure for this is shown. No additional secondary PDP context activation is required for multiple service sets. Dynamic requests for new services are accepted by RAB establishment and release between WTRU 405 and eNodeB 410.

Referring to FIG. 4, at step 422, the WTRU 405 sends a PDP context activation request message to the MME 415. The content of the message includes, for example, NSAPI, transaction identifier (TI), PDP type, PDP address (if a static PDP address is requested), access point name (APN), QoS, service list, and the like.

Note that the meaning of the QoS request is distinct from the current PDP context activation procedure. Currently, QoS requests apply only to this PDP context. The primary PDP context and the secondary PDP context and the RABs mapped to them respectively may have different QoS. According to the present invention, QoS is a range that applies to all RABs belonging to this PDP context, and it is possible that the WTRU 405 has only one PDP context for one IP address. The service list is a new parameter that provides the range of IP services that the WTRU 405 wishes to establish with the core network (CN) in this PDP context.

At step 424, MME 415 confirms the PDP context activation request using the PDP type, PDP address, and APN provided by WTRU 405. The MME 415 may limit the requested QoS attribute, taking into account its functionality and current load. The MME 415 associates a PDP context creation request message (PDP type, PDP address, APN, negotiated QoS, TEID, NSAPI, Mobile Station International Integrated Services Digital Network (ISDN) number (MSISDN), etc.) with the associated anchor node 420. (Step 426). At step 428, for a valid PDP context request, anchor node 420 will create a PDP entry. A different PDP is associated with each service requested. In this case, if all services are provided through the same gateway (ie anchor node 420) / by the same gateway, there is one IP address and multiple port numbers. Each port number is associated with a service that is activated. Additionally, at step 428, anchor node 420 generates billing information for a valid PDP context request. Each service will be billed separately according to different criteria. For example, video calls can be billed differently than text messages. Therefore, each service will have a different billing ID. The anchor node 420 then sends a PDP context creation response message to the MME 415 (step 430).

In steps 432, 434, 436 and 438, RAB setup is performed by the RAB Assignment / RB Setup procedure as it is currently performed. The QoS exchanged between the RAN (eg, eNodeB 510) and the CN is for a particular RAB, which must be in the negotiated QoS of the PDP context. The ID of the PDP context associated with this RAB is passed to the WTRU 405. If the QoS of the RAB is downgraded from the negotiated QoS of the PDP context, no PDP context changes are needed because more RAB / RBs can be allocated for the same service if more resources are available. .

If all of the above steps are performed successfully, the MME 415 returns a PDP context activation received message (PDP type, PDP address, TI, negotiated QoS, radio priority, etc.) to the WTRU 405 (step 440). ). At this point, a GPRS Tunneling Protocol (GTP) tunnel is established between the first RB associated with the PDP context and the anchor node 420 and the eNodeB 410 (steps 442 and 444).

As shown in procedure 450 of FIG. 4, for every new service requested at WTRU 405, a new RB / RAB needs to be established (step 452). The WTRU 405 sends a message to the eNodeB 410 to request a new RB for the new service (step 454). Service-related QoS requests may be delivered via messages. eNodeB 410 may check the availability of resources (step 456) and may reject the request if there are not enough resources. eNodeB 410 sends a request for a new RAB to MME 415 (step 458). Since the WTRU 405 knows the NSAPI from the first RAB establishment (ie, the RAB established during the primary PDP context activation), the MME 415 will know which PDP context the request should associate with.

MME 415 notifies anchor node 420 that a new RAB has been established for a given PDP context (step 460). The anchor node 420 allocates the necessary resources for the service at the tunnel end, updates the billing and routing information, and sends a response back to the MME 415 (step 462).

RAB allocation and RB setup procedures (steps 464, 466, 468, and 470) are performed in a conventional manner. Steps 464, 466, 468, and 470 can be performed in parallel with steps 460 and 462, which can reduce delay. The steps of procedure 450 are repeated whenever there is a new service requested in step 452.

According to another embodiment of the present invention, FIG. 5 illustrates PDP context activation and RAB allocation in LTE system 500 including WTRU 505, eNodeB 510, MME 515, and anchor node 520. The procedure for this is shown. In the proposed procedure, no additional secondary PDP context activation is needed for multiple service sets. Dynamic requests for new services are accepted by the RB establishment and release between the WTRU 505 and the eNodeB 510.

5, the WTRU 505 sends a PDP context activation request message to the MME 515 (step 525). In the request, NSAPI, APN, list of services and corresponding QoS requirements are defined. Unlike conventional PDP context activation procedures that provide only one NSAPI and one APN, the proposed procedure will have a list of NSAPIs, APNs, and services negotiated and established in one PDP context activation procedure. Keep in mind. If different service requests occur later, no additional PDP context activation procedure is needed, thus limiting signaling between the WTRU 505 and the eNodeB 510.

Still referring to FIG. 5, at step 530, the MME 530 confirms the PDP context activation request, selects at least one APN, maps the APN to the anchor node 520, and determines the GTP TEID and NSAPI list. do. The WTRU 505 lists all the services that need to be activated using the APN list. Each service exhibits a different NSAPI and QoS profile. At step 535, MME 515 sends a PDP context creation request message to anchor node 520. At step 540, for a valid PDP context request, anchor node 520 will create a PDP entry. Different PDPs are associated with each service requested. In this case, if all services are provided through the same gateway (ie anchor node 520) / by the same gateway, then there is one IP address and multiple port numbers. Each port number is associated with a service that is activated. Additionally, at step 540, anchor node 520 generates billing information for a valid PDP context request. Each service will be billed separately according to different criteria. For example, video calls can be billed differently than text messages. Therefore, each service will have a different billing ID.

At this point, the PDP context activation procedure is completed at anchor node 520. The anchor node 520 then initiates an acknowledgment phase of operation by sending a PDP context creation response message back to the MME 515 (step 545), which initiates the RAN (e.g. 510)] (step 550). The MME sends information about the number of services being activated and associated ASAPI, PDP address, gateway TEID, and WTRU ID (temporary ID), whereby each traffic flow is routed accordingly. The RAN (e.g., eNodeB 510) then activates the RAB for each service and maps each flow to an associated ID (step 555) to tunnel (direct tunnel or traditional GPRS dual tunnel (RANAP and GTP)] (step 560). At step 565, MME 515 terminates the activation procedure by notifying the WTRU 505 that the activation process was successful. The MME 515 sends a list of all services that have been successfully activated. If it fails to activate certain services, the MME 515 indicates the failed service and the cause of the failure. At step 570, the WTRU 505 and / or the RAN (eg, eNodeB 510) may activate / deactivate the physical RB / channel based on the availability of the data flow being transmitted.

For more services that need to be established later, the above procedure will be limited to the RB setup between WTRU 505 and eNodeB 510.

During activation of the PDP context, the RAN and CN negotiate QoS parameters for the PDP context, such as maximum bit rate, guaranteed bit rate, maximum delay, and the like. The QoS profile is then delivered directly to the RAN in the RAB assignment procedure. The QoS requirements of all assigned RABs / RBs under the PDP context must be within the QoS constraints of the PDP context.

6 illustrates multiple PDP contexts established for multiple PDNs in wireless communication system 600. System 600 includes a WTRU 605, an eNodeB 610, an MME 615, an anchor node 620, and an APN 625A-625E. If the new service requires a new APN and hence a new access gateway, the MME 615 must allocate a new tunnel between the eNodeB 610 and the new access gateway. The WTRU 605 is likely to obtain a different IP address from each PDN. Therefore, different PDP contexts are established. The procedures for establishing a PDP context are the same as described above.

Through the proposed PDP context procedure, one PDP context is sufficient for multiple services of one IP address for the WTRU 605. Establishing a secondary PDP context may be optional (eg, if the operator wishes to bundle certain services under the secondary PDP context). The processing of the secondary PDP context is the same as that currently performed.

Multiple RAB / RBs can be established and associated with the PDP context. eNodeB 610 should enable multiple radio bearers for multiple streams unless violated within the bit rate and delay budget (set during PDP context activation). If a request for an additional bearer from eNodeB 610 violates QoS constraints, then eNodeB 610 indicates that the current request requires a change in the PDP context and / or activation of a secondary PDP context. Notify the WTRU 605. The number of parallel flows allowed for the PDP context can be defined. If the WTRU 605 has used all of the services allowed, then the request of the WTRU 605 should be rejected.

Currently, there is a one-to-one relationship between NSAPI, RAB and PDP contexts. In the packet area, there is also a one-to-one relationship with the RB ID. With the proposed change in the PDP context procedure, a new mapping needs to be established. The meaning of NSAPI will remain the same. In the WTRU 605, the NSAPI identifies a PDP Service Access Point (SAP). At MME 615 and anchor node 620, the NSAPI identifies the PDP context associated with the Mobility Management (MM) context indicating which state the WTRU 605 is in. The MM context has all the information associated with the WTRU 605, such as QoS, different security information, etc. while operating within the network. The RAB ID must contain information about both the NSAPI (ie the PDP context with which the RAB is associated) and the unique ID for the RAB. Therefore, each RAB is mapped to a PDP context. How to form the RAB ID is implementation dependent. The RB ID may be the same as the RAB ID.

Examples

Embodiment 1. A long term evolution (LTE) communication system comprising a wireless transmit / receive unit (WTRU), an evolved Node-B, a mobility management entity (MME), and an anchor node:

(a) establishing a first radio bearer associated with a packet data protocol (PDP) context and a general packet radio service (GPRS) tunneling protocol (GTP) between the anchor node and the evolved Node-B;

(b) the WTRU sending a message to the evolved Node-B requesting a new radio bearer (RB) for a new service;

(c) the evolved Node-B sending the message to the MME, wherein the MME maps an access point name (APN) to the anchor node, and a GTP tunnel endpoint identifier (TEID) and network layer service. Sending a message to the MME, determining a list of access point identifiers (NSAPI); And

(d) the MME notifying the anchor node that there is a new radio access bearer (RAB) established for a given PDP context.

How to include.

Embodiment 2 The method of Embodiment 1, wherein the anchor node allocates the necessary resources for the service at the end of the tunnel, updates billing and routing information, and sends back a response to the MME.

Embodiment 3 The method of embodiment 1 or 2, wherein a service related quality of service (QoS) request is conveyed via the message.

Embodiment 4 The method of any one of embodiments 1-3, wherein the evolved Node-B checks the availability of resources.

Embodiment 5 The method of embodiment 4, wherein the evolved Node-B rejects the message if there are not enough resources.

Example 6 In a Long Term Evolution (LTE) Communication System:

(a) evolved Node-B;

(b) a wireless transmit / receive unit (WTRU) configured to send a message requesting a new radio bearer (RB) for a new service;

(c) an anchor node configured to establish a first radio bearer between itself and the evolved Node-B, wherein the first radio bearer is a packet data protocol (PDP) context and a general packet radio service (GPRS) tunneling protocol ( The anchor node, associated with the GTP);

(d) map an access point name (APN) to the anchor node, determine a GTP tunnel endpoint identifier (TEID) and network layer service access point identifier (NSAPI) list, and establish a new radio access bearer established for a given PDP context; Mobility management entity (MME) configured to notify the anchor node that a (RAB) is present

Long term evolution (LTE) communication system comprising a.

Embodiment 7 The long term of Embodiment 6, wherein the anchor node allocates the necessary resources for the service at the end of the tunnel, updates billing and routing information, and sends back a response to the MME. Evolution (LTE) communication system.

Embodiment 8 The Long Term Evolution (LTE) communication system of Embodiment 6 or Embodiment 7, wherein a service related quality of service (QoS) request is conveyed via the message.

Embodiment 9. The Long Term Evolution (LTE) communication system of any one of Embodiments 6-8, wherein the evolved Node-B checks for availability of resources.

Embodiment 10 The Long Term Evolution (LTE) communication system of Embodiment 9, wherein the evolved Node-B rejects the message if there are not enough resources.

Embodiment 11. A long term evolution (LTE) communication system comprising a wireless transmit / receive unit (WTRU), an evolved Node-B, a mobility management entity (MME), and an anchor node:

(a) Packet Data Protocol (PDP) context activation including a list of network layer service access point identifiers (NSAPIs), service and access point names (APNs) for which the WTRU is negotiated and established within a single PDP context activation procedure. Sending a request message to the MME;

(b) the MME confirming the PDP context activation request message and sending a PDP context creation request message to the anchor node;

(c) the anchor node generating a new PDP entry and a billing identifier;

(d) the anchor node sending a PDP context creation response message to the MME;

(e) establishing a radio access bearer (RAB) between the evolved Node-B and the MME; And

(f) establishing a radio bearer (RB) between the WTRU and the evolved Node-B.

How to include.

Embodiment 12 The system of Embodiment 11, wherein the MME maps an APN to the anchor node, determines a General Packet Radio Service (GPRS) Tunneling Protocol (GTP) tunnel endpoint identifier (TEID) and NSAPI list, and a constant PDP context. Notify the anchor node that there is a new RAB established for.

Embodiment 13. The method of embodiment 12, wherein the anchor node allocates the necessary resources for the service at the end of the tunnel.

Embodiment 14 The method of any one of embodiments 11-13, wherein a service related quality of service (QoS) request is communicated to the MME via the PDP context activation request message.

Embodiment 15 The method of any one of embodiments 11-14, wherein the evolved Node-B checks for availability of resources.

Example 16. A Long Term Evolution (LTE) Communication System:

(a) evolved Node-B;

(b) send a packet data protocol (PDP) context activation request message containing a list of network layer service access point identifiers (NSAPI), services and access point names (APNs) negotiated and established within a single PDP context activation procedure; A wireless transmit / receive unit (WTRU) configured to send;

(c) an anchor node configured to receive a PDP context creation request message directed to it, generate a new PDP entry and billing identifier, and send a PDP context creation response message;

(d) a mobility management entity (MME) configured to receive the PDP context creation response message

Long term evolution (LTE) communication system comprising a.

Embodiment 17 The system of Embodiment 16, wherein a radio access bearer (RAB) is established between the evolved Node-B and the MME, and a radio bearer (RB) is established between the WTRU and the evolved Node-B. Long Term Evolution (LTE) communication system.

Embodiment 18 The system of Embodiment 17, wherein the MME maps an APN to the anchor node, determines a General Packet Radio Service (GPRS) Tunneling Protocol (GTP) tunnel endpoint identifier (TEID) and NSAPI list, and a constant PDP context. Long term evolution (LTE) communication system to notify the anchor node that there is a new RAB established for.

Embodiment 19 The Long Term Evolution (LTE) communication system of Embodiment 18, wherein the anchor node allocates the necessary resources for the service at the end of the tunnel.

Embodiment 20 The long term evolution of any one of embodiments 16-19, wherein a service related quality of service (QoS) request is communicated to the MME via the PDP context activation request message. LTE) communication system.

Embodiment 21 The Long Term Evolution (LTE) communication system of any one of Embodiments 16-20, wherein the evolved Node-B checks for availability of resources.

Although the features and components of the present invention have been described above in the preferred embodiments above with particular combinations, each feature and component of the present invention is solely without other features and components within the above preferred embodiments. It may be used, or in combination with other features and components of the present invention or in part, except for some. The methods or flowcharts provided herein can be implemented in computer programs, software, or firmware embedded in a computer readable storage medium executed by a general purpose computer or processor. Examples of computer-readable storage media include read only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magnetic optical media, CD-ROMs. Optical media such as discs, and DVDs.

Examples of suitable processors include general purpose processors, special purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors in conjunction with DSP cores, controllers, microcontrollers, application specific integrated circuits (ASICs). Field programmable gate array (FPGA) circuits, any type of integrated circuits (ICs), and / or state machines.

The processor associated with the software may be used to implement a radio frequency transceiver for use in a wireless transmit / receive unit (WTRU), user equipment (UE), terminal, base station, radio network controller (RNC), or any host computer. WTRUs include cameras, video camera modules, videophones, speakerphones, vibrators, speakers, microphones, television transceivers, handfree headsets, keyboards, Bluetooth® modules, frequency modulation (FM) wireless units, liquid crystal display (LCD) display units, organic To be used with modules implemented in hardware and / or software such as light emitting diode (OLED) display units, digital music players, media players, video game player modules, Internet browsers, and / or any wireless local area network (WLAN) modules. Can be.

Claims (21)

A long term evolution (LTE) communication system comprising a wireless transmit / receive unit (WTRU), an evolved Node-B, a mobility management entity (MME), and an anchor node: (a) establishing a first radio bearer associated with a packet data protocol (PDP) context and a general packet radio service (GPRS) tunneling protocol (GTP) between the anchor node and the evolved Node-B; (b) the WTRU sending a message to the evolved Node-B requesting a new radio bearer (RB) for a new service; (c) the evolved Node-B sending the message to the MME, where the MME maps an access point name (APN) to the anchor node, a GTP tunnel endpoint identifier (TEID) and network layer service access. Sending a message to the MME to determine a list of Point Identifiers (NSAPI); And (d) the MME notifying the anchor node that there is a new radio access bearer (RAB) established for a given PDP context. How to include. 2. The method of claim 1 wherein the anchor node allocates the necessary resources for the service at the end of the tunnel, updates billing and routing information, and sends back a response to the MME. The method of claim 1, wherein a service related quality of service (QoS) request is communicated via the message. The method of claim 1, wherein the evolved Node-B checks for availability of resources. 5. The method of claim 4, wherein the evolved Node-B rejects the message if there are not enough resources. In Long Term Evolution (LTE) communication systems: (a) evolved Node-B; (b) a wireless transmit / receive unit (WTRU) configured to send a message requesting a new radio bearer (RB) for a new service; (c) an anchor node configured to establish a first radio bearer between itself and the evolved Node-B, wherein the first radio bearer is a packet data protocol (PDP) context and a general packet radio service (GPRS) tunneling protocol (GTP). The anchor node; (d) map an access point name (APN) to the anchor node, determine a GTP tunnel endpoint identifier (TEID) and network layer service access point identifier (NSAPI) list, and establish a new radio access bearer established for a given PDP context; Mobility management entity (MME) configured to notify the anchor node that a (RAB) is present Long term evolution (LTE) communication system comprising a. 7. The Long Term Evolution (LTE) of claim 6, wherein the anchor node allocates the necessary resources for the service at the end of the tunnel, updates billing and routing information, and sends back a response to the MME. A) communication system. 10. The Long Term Evolution (LTE) communication system of claim 6, wherein service related quality of service (QoS) requests are communicated via the message. 7. The Long Term Evolution (LTE) communication system of claim 6, wherein the evolved Node-B checks for availability of resources. 10. The Long Term Evolution (LTE) communication system of claim 9, wherein the evolved Node-B rejects the message if there are not enough resources. A long term evolution (LTE) communication system comprising a wireless transmit / receive unit (WTRU), an evolved Node-B, a mobility management entity (MME), and an anchor node: (a) Packet Data Protocol (PDP) context activation including a list of network layer service access point identifiers (NSAPIs), service and access point names (APNs) for which the WTRU is negotiated and established within a single PDP context activation procedure. Sending a request message to the MME; (b) the MME confirming the PDP context activation request message and sending a PDP context creation request message to the anchor node; (c) the anchor node generating a new PDP entry and a billing identifier; (d) the anchor node sending a PDP context creation response message to the MME; (e) establishing a radio access bearer (RAB) between the evolved Node-B and the MME; And (f) establishing a radio bearer (RB) between the WTRU and the evolved Node-B. How to include. 12. The method of claim 11, wherein the MME maps an APN to the anchor node, determines a General Packet Radio Service (GPRS) Tunneling Protocol (GTP) tunnel endpoint identifier (TEID) and NSAPI list, and establishes for a certain PDP context. Notify the anchor node that a new RAB exists. 13. The method of claim 12 wherein the anchor node allocates the necessary resources for the service at the end of the tunnel. 12. The method of claim 11 wherein a quality of service (QoS) request is communicated to the MME via the PDP context activation request message. 12. The method of claim 11, wherein the evolved Node-B checks for availability of resources. In Long Term Evolution (LTE) communication systems: (a) evolved Node-B; (b) send a packet data protocol (PDP) context activation request message containing a list of network layer service access point identifiers (NSAPI), services and access point names (APNs) negotiated and established within a single PDP context activation procedure; A wireless transmit / receive unit (WTRU) configured to send; (c) an anchor node configured to receive a PDP context creation request message directed to it, generate a new PDP entry and billing identifier, and send a PDP context creation response message; (d) a mobility management entity (MME) configured to receive the PDP context creation response message Long term evolution (LTE) communication system comprising a. 17. The long term of claim 16 wherein a radio access bearer (RAB) is established between the evolved Node-B and the MME and a radio bearer (RB) is established between the WTRU and the evolved Node-B. Evolution (LTE) communication system. 18. The method of claim 17, wherein the MME maps an APN to the anchor node, determines a General Packet Radio Service (GPRS) Tunneling Protocol (GTP) tunnel endpoint identifier (TEID) and NSAPI list, and establishes for a certain PDP context. Long term evolution (LTE) communication system for notifying the anchor node that a new RAB exists. 19. The Long Term Evolution (LTE) communication system of claim 18, wherein the anchor node allocates the necessary resources for the service at the end of the tunnel. 18. The Long Term Evolution (LTE) communication system of claim 17, wherein a service related quality of service (QoS) request is communicated to the MME via the PDP context activation request message. 18. The Long Term Evolution (LTE) communication system of claim 17, wherein the evolved Node-B checks for availability of resources.

Images