Sign In to Follow Application
View All Documents & Correspondence

A Method Of Deactivating Packet Data Protocol

Abstract: A method is provided of deactivating PDP Context upon transfer of a connection with a user terminal between a femtocell base station and a macrocell base station the method comprising: the femto base station receiving a message including a first identifier of a PDP Context altering the identifier of a PDP Context to a second identifier and forwarding the altered message to the core network the core network receiving a message including an identifier determines that the received identifier does not match the identifier that it expects and so deactivates the PDP Context.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
15 October 2012
Publication Number
51/2015
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
Parent Application
Patent Number
Legal Status
Grant Date
2019-05-30
Renewal Date

Applicants

ALCATEL LUCENT
3 avenue Octave Gréard F 75007 Paris

Inventors

1. SAPIANO Philip C.
122 Brook Drive Corsham SN13 9AY Wiltshire
2. BRADLEY Nigel
41 North Meadow Road Cricklade SN6 6LT
3. BREND Graham R.
78 Dovers Park Bathford Bath BA1 7UE
4. PUTMAN Tony
Hollyhurst Brinkworth Chippenham SN15 5AQ Wiltshire

Specification

DEACTIVATING PACKETDATA PROTOCOL CONTEXT
Field of the Invention
The present invention relates to telecommunications, in particular to wireless
telecommunications.
Description of the Related Art
Wireless telecommunications systems are well-known. Many such systems are
cellular, in that radio coverage is provided by a bundle of radio coverage areas known
as cells. A base station that provides radio coverage is located in each cell. Traditional
base stations provide coverage in relatively large geographic areas and the
corresponding cells are often referred to as macrocells.
It is possible to establish smaller sized cells within a macrocell. Cells that are
smaller than macrocells are sometimes referred to as microcells, picocells, or
femtocells, but we use the term femtocells generically for cells that are smaller than
macrocells. One way to establish a femtocell is to provide a femtocell base station
that operates within a relatively limited range within the coverage area of a macrocell.
One example of use of a femtocell base station is to provide wireless communication
coverage within a building.
The femtocell base station is of a relatively low transmit power and hence each
femtocell is of a small coverage area compared to a macrocell.
Femtocell base stations are intended primarily for users belonging to a
particular home or office. Femtocell base stations may be private access or public
access. In femtocell base stations that are private access, access is restricted only to
registered users, for example family members or particular groups of employees. In
femtocell base stations that are public access, other users may also use the femtocell
base station, subject to certain restrictions to protect the Quality of Service received by
registered users.
One known type of Femtocell base station uses a broadband Internet Protocol
connection as "backhaul", namely for connecting to the core network. One type of
broadband Internet Protocol connection is a Digital Subscriber Line (DSL). The DSL
connects a DSL transmitter-receiver ("transceiver") of the femtocell base station to the
core network. The DSL allows voice calls and other services provided via the
femtocell base station to be supported. The femtocell base station also includes a radio
frequency (RF) transceiver connected to an antenna for radio communications.
Femtocell base stations are sometimes referred to as femtos.
Femtos are low power user-deployed base stations that are suitable for
residential or business environments, such as factories or offices, as they typically
have a range of tens of metres. They have auto-configuring and self -optimising
capabilities so as to enable simple non-optimised deployment by users, often known
as plug-and-play deployment. Femtos automatically integrate themselves into an
existing network of macrocell base stations.
Assuming the user terminal has a packet switched session connected to the
macrocellular network, when the session moves to connection with a femto, the
associated Packet Data Protocol (PDP) Context has to be deactivated in order to
indicate this change to the network, for example to allow the network to support
differentiated billing and to notify the user terminal of the new applicable billing
tariff. The same applies when the user terminal has a packet switched session
connected to the femto that moves to connection with the macrocellular network. One
reason is to provide differential billing between when a user terminal is connected to a
femto and when the user terminal is instead connected to a macrocell. Another reason
for such PDP Context deactivation is when the femto has performed some
manipulation of the PDP context which will no longer work on the macrocell, PDP
Context deactivation enables the user terminal to then reactivate with a fresh PDP
Context usable in connection via the macrocell.
One known approach is to implement a solution in the Serving GPRS Support
Node (SGSN), where GPRS denotes General Packet Radio Service, so that upon the
SGSN detecting that the connection with the user terminal moves from the femto to
the macrocellular network then the PDP Context is deactivated. Another known
approach is for the Radio Network Controller (RNC) in the macrocellular network to
control PDP Context deactivation. Both these approaches are complex and require
changes in the macrocellular network.
Summary
The reader is referred to the appended independent claims. Some preferred
features are laid out in the dependent claims.
An example of the present invention is a method of deactivating PDP Context
upon transfer of a connection with a user terminal between a femtocell base station
and a macrocell base station, the method comprising: the femtocell base station
receiving a message including a first identifier of a PDP Context , altering the
identifier of a PDP Context to a second identifier, and forwarding the altered message
to the core network; the core network receiving a further message including an
identifier, the core network determining that the received identifier does not match the
identifier that the core network expects and so deactivating the PDP Context.
Some preferred embodiments provide PDP Context deactivation upon, for
example, transfer from macrocell base station to femtocell base station, hence
allowing the core network to support differentiated billing, for example the ability to
identify when a call is via a femto as so can be billed at a lower tariff. More generally
the femtocell base station may provide services to user terminals which are linked to
PDP Contexts and such services will not work whilst the user terminal is macrocellconnected.
Timely PDP Context deactivation enables PDP Context reactivation, and
hence continued service provision, promptly upon the user terminal reconnecting to a
femto. Upon connection to the macrocell base station, prompt PDP Context
deactivation enables the service to be re-established via the macrocellular network
only.
Preferred embodiments are easy to implement as no substantial changes are
required to the macrocellular network or SGSN.
Brief Description of the Drawings
Embodiments of the present invention will now be described by way of
example and with reference to the drawings, in which:
Figure 1 is a diagram illustrating a wireless communications network
according to a first embodiment of the present invention,
Figure 2 is a diagram illustrating an example femtocell base station
deployment within one macrocell shown in Figure 1,
Figure 3 is a message sequence diagram illustrating Network Service Access
Point Identifier (NSAPI) translation by the femto during an Activate PDP Context
request/accept procedure,
Figure 4 is a message sequence diagram illustrating NSAPI translation by the
femto during a Service Request/Accept procedure,
Figure 5 is a message sequence diagram illustrating NSAPI translation by the
femto during a Routing Area Update Request/Accept procedure,
Figure 6 is a message sequence diagram illustrating how a mismatch between
expected and received NSAPI upon cell reselection from the femtocell to the
macrocell causes deactivation of PDP Context,
Figure 7 is a message sequence diagram illustrating how a mismatch between
expected and received NSAPI upon cell reselection from the macrocell to the
femtocell causes deactivation of PDP Context, and
Figure 8 is a message sequence diagram illustrating how when a NSAPI value
is being used by a femto for identifying a PDP Context to an SGSN, but is requested
for use by another user terminal, the PDP Context is reactivated with a new NSAPI
value.
In Figures 3 to 8, various steps have been denoted step a, step b etc. All steps
denoted step a etc should not be assumed to be identical throughout the described
examples, in other words they are intended to be example-specific referring to the
relevant figure.
Detailed Description
We will describe a network including femtocell base stations, referring to
Figures 1 and 2. After that, we consider with reference to Figures 3 to 5 how femtos
translate NSAPI values. We will then go on to explain, by reference to Figures 6 and
7, how a NSAPI mismatch seen in the SGSN triggers PDP Context deactivation. After
that, referring to Figure 8, we consider how when a NSAPI value is being used by a
femto for identifying a first PDP Context to an SGSN, but is requested for use by the
same user terminal in respect of a further PDP Context, the first PDP Context is
reactivated with a new NSAPI value.
Network
As shown in Figures 1 and 2, a network 10 for wireless communications,
through which a user terminal 34 may roam, includes two types of base station,
namely macrocell base stations and femtocell base stations (the latter being sometimes
called "femtos"). One macrocell base station 22 is shown in Figures 1 and 2 for
simplicity. Each macrocell base station has a radio coverage area 24 that is often
referred to as a macrocell. The geographic extent of the macrocell 24 depends on the
capabilities of the macrocell base station 22 and the surrounding geography.
Within the macrocell 24, each femtocell base station 30 provides wireless
communications within a corresponding femtocell 32. A femtocell is a radio coverage
area. The radio coverage area of the femtocell 32 is much less than that of the
macrocell 24. For example, the femtocell 32 corresponds in size to a user's office or
home.
As shown in Figure 1, the network 10 is managed by a radio network
controller, RNC, 170. The radio network controller, RNC, 170 controls the operation,
for example by communicating with macrocell base stations 22 via a backhaul
communications link 160. The radio network controller 170 maintains a neighbour list
which includes information about the geographical relationship between cells
supported by base stations. In addition, the radio network controller 170 maintains
location information which provides information on the location of the user
equipment within the wireless communications system 10. The radio network
controller 170 is operable to route traffic via circuit-switched and packet-switched
networks. For circuit-switched traffic, a mobile switching centre 250 is provided with
which the radio network controller 170 may communicate. The mobile switching
centre 250 communicates with a circuit-switched network such as a public switched
telephone network (PSTN) 210. For packet-switched traffic, the network controller
170 communicates with Serving General packet radio service Support Nodes (SGSNs)
220 and a Gateway General packet radio Support Node (GGSN) 180. The GGSN
then communicates with a packet-switch core 190 such as, for example, the Internet.
The MSC 250, SGSN 220, GGSN 180 and operator IP network constitute a socalled
core network 253. The SGSN 220 and GGSN 180 are connected by an operator
IP network 215 to a femtocell controller/gateway 230.
The femtocell controller/gateway 230 is connected via the Internet 190 to the
femtocell base stations 30. These connections to the femtocell controller/gateway 230
are broadband Internet Protocol connections ("backhaul") connections. The femtocell
controller/gateway is often referred to as the femto-gateway.
The femto-gateway 230 and femtocell base stations 30 constitute a femto
network 37.
The core network 253, RNCs 170 and macrocell base stations 22 constitute a
macrocellular network.
In Figure 2, three femtocell base stations 30 and corresponding femtocells 32
are shown for simplicity.
It is possible for a mobile terminal 34 within the macrocell 24 to communicate
with the macrocell base station 22 in known manner. When the mobile terminal 34
enters into a femtocell 32 for which the mobile terminal is registered for
communications within the femtocell base station 30, it is desirable to handover the
connection with the mobile terminal from the macrocell to the femtocell. In the
example shown in Figure 2, the user of mobile terminal 34 is a preferred user of the
nearest 32' of the femtocells 32.
As shown in Figure 2, the femtocell base stations 30 are connected via the
broadband Internet Protocol connections ("backhaul") 36 to the core network (not
shown in Figure 2) and hence the rest of the telecommunications "world" (not shown
in Figure 2). The "backhaul" connections 36 allow communications between the
femtocell base stations 30 through the core network (not shown). The macrocell base
station is also connected to the core network (not shown in Figure 2).
Translation of NSAPI values by the femto
Non Access Stratum (NAS) signalling is signalling according to the NAS
protocol defined in 3GPP Technical Specification 24-008 Version 5.16.0 (2006-06)
for signalling between a user terminal (UE) and the core network. NAS signalling is
used for mobility management, connection management, call control and session
management which includes Packet Data Protocol (PDP) Context control.
A PDP Context is a data structure present in the Serving Gateway Support
Node (SGSN) which contains a user terminal's session information when the user
terminal has an active data session. The data includes the user terminal's IP address,
and a Network (layer) Service Access Point Identifier (NSAPI). The NSAPI is an
identifier of a PDP Context, with a value between 5 and 15 selected by the user
terminal during PDP Context activation. A user terminal may have more than one
simultaneously active PDP context to transfer packet data through various IP tunnels.
The applicable femto 30 intercepts and translates part of the NAS signalling
between the user terminal 34 and SGSN 220, and maintains this translation whilst the
user terminal remains connected in the femto network 37. In this way any subsequent
messages between the user terminal and the SGSN appear to have end-to-end Internet
Protocol (IP) tunnel integrity.
Accordingly, when the user terminal reselects to a macrocell and the user
terminal performs a Routing area update, the previous translation occurring in the
femto network results in a mismatch between the received NSAPI value compared
with that expected, which causes the PDP Context to be shutdown. This is explained
in more detail below.
The telecommunications standard, namely 3GPP Technical Specification 24-
008 Version 5.16.0 (2006-06) requires each PDP Context to be associated with a
different NSAPI value, where NSAPI is an integer value in the range 5 to 15. The
femto network 37, more specifically in this example the femto 30, translates every
occurrence of the NSAPI value in messages between the user terminal and SGSN via
the femto network. This is shown by reference to Figures 3, 4 and 5 below.
(a) Femto translation of NSAPI during Activate PDP Context
As shown in Figure 3, an Activate PDP Context Request is sent (step a) from
the user terminal 34 to the femto 30. The Activate PDP Context Request is a NAS
message including an NSAPI value of 5 and an Access Point Name (APN). The APN
identifies the IP packet data network (PDN) that the service is to be connected to from
the GGSN. The femto translates (step b) the NSAPI value in the Request to 15 and
forwards (step c) this amended Request to the SGSN 220. The SGSN stores the
International Mobile Subscriber Identity (IMSI) identifying the user terminal
associated with the received NSAPI of 15, and replies (step d) with a Radio Access
Bearer (RAB) Assignment Request having a Radio Access Bearer identity (RAB ID)
of 15. The femto translates the RAB ID to 5 (to match the value received in the
original Request message) and sends (step e) a Radio Bearer Setup (RAB ID=5)
message to the user terminal. The SGSN then sends (step f) an Activate PDP Context
Accept message to the femto which forwards (step g) that message to the user
terminal.
The RAB ID and NSAPI have the same value(s), and in this example the femto
translates the NSAPI/RAB ID of value 5 from the user terminal to the value 15
towards the SGSN, and vice versa. The femto also stores the IMSI of the user
terminal.
(b) Femto translation of NSAPI during a Service Request
A Service Request is a request to go from idle mode to active mode so
allocating radio resources. Such requests typically happen many times during a PDP
Context.
As shown in Figure 4, a Service Request is sent (step a) from the user terminal
to the femto. The Service Request includes an indication of the reason for the service
request (data in this example) and an NSAPI value of 5.
The femto translates (step b) the NSAPI value to 15 before forwarding (step c)
the amended Service Request to the SGSN. The SGSN replies (step d) to the femto
with a RAB Assignment request that includes a RAB ID of 15. The RAB ID of 15 is
translated to 5 by the femto and included in a Radio Bearer Setup message sent (step
e) from the femto to the user terminal.
The RAB ID and NSAPI take identical values, in an exact 1:1 mapping. The
femto translates the RAB ID in each RAB Assignment message from the SGSN into
the corresponding RAB ID in the Radio Bearer setup message to be sent to the user
terminal.
(c Femto translation of NSAPI during Routing Area Update (RAU)
As shown in Figure 5, the user terminal periodically sends (step a) a routing
area update (RAU) request message to the femto. The message includes an NSAPI of
5. The femto translates (step b) the NSAPI value to 15 and forwards (step c) the
amended message to the SGSN. The SGSN replies (step d) with a RAU Accept
message including an NSAPI value of 15. The femto translates the NSAPI value to 5
and sends (step e) the amended RAU Accept message to the user terminal.
Activated PDP Context operation
With the NSAPI translations described above, whilst the user terminal is
connected to a femto, the PDP Context may be activated and normal data transfer will
occur. The user terminal may move between an inactive idle mode and an active
connected mode whilst the PDP Context is maintained, for example preserved in the
SGSN whilst the user terminal is in idle mode.
W en the user terminal connection moves from the femto to the macrocellular
network, namely in a cell reselection, the femto is not informed so the femto network
does not know of this reselection.
PDP Context deactivation upon reselection to macrocell
As shown in Figure 6, when the user terminal connects to a macrocell base
station, the user terminal sends (step a) a routing area update request to the radio
network controller 170. This request includes location information and an NSAPI
value of 5. The RNC does not translate the NSAPI value but merely forwards the
received RAU request including the NSAPI value of 5 to the SGSN. In consequence
the SGSN detects a mismatch between the received NSAPI value of 5 and the NSAPI
value of 15 that it expects from when the PDP Context was activated.
In consequence, in accordance with 3GPP Technical Specification 24-008
version 5.16.0 (2006-06), the SGSN deactivates (step c) the PDP Context.
Furthermore, the SGSN sends (step d) a RAU Accept message with no active
NSAPI value indicated. The RNC forwards (step e) this message. On receiving this
message, the user terminal also deactivates its PDP Context according to that relevant
section 4.7.5.1.3 of 3GPP Technical Specification 24-008 version 5.16.0 (2006-06).
The relevant part of the 3GPP Technical Specification 24-008 version 5.16.0 (2006-
06) states:
4.7.5.1.3 Normal and periodic routing area updating
procedure accepted by the network
If the PDP context status information element is included in
ROUTING AREA UPDATE REQUEST message, then the network
shall deactivate all those PDP contexts locally (without peer to peer
signalling between the MS and the network), which are not in SM state
PDP-INACTIVE on network side but are indicated by the MS as being
in state PDP-INACTIVE.
If the PDP context status information element is included in
ROUTING AREA UPDATE ACCEPT message, then the MS shall
deactivate all those PDP contexts locally (without peer to peer
signalling between the MS and network), which are not in SM state
PDP-INACTrVEin the MS but are indicated by the network as being
in state PDP-INACTiVE.".
As described above, the femto ensures that PDP Context deactivation is
performed when the user terminal reselects to a macrocell base station. The user
terminal thereafter reactivates the PDP Context so as to continue data transfer via the
macrocell base station. This deactivation/reactivation is a trigger for billing at the
tariff of the macrocellular network as opposed to billing at the tariff of the femto, and
notifying the user terminal of this change.
PDP Context deactivation upon reselection to femto from macrocell
The femto also deactivates a PDP Context upon a user terminal connected to a
macrocell base station reselecting to a femto.
As shown in Figure 7, the user terminal sends (step a) a routing area update
(RAU) request to the femto when it reselects to the femto from a macrocell base
station. The request includes a location identifier and NSAPIs of value of 5 in this
example.
The femto removes the NSAPI value then forwards (step b) the amended RAU
request to the SGSN. This can be considered a corruption or translation of the NSAPI
value. The SGSN expects NSAPI value of 5 but sees none, so in consequence of this
mismatch, deactivates (step c) the PDP Context.
Furthermore, the SGSN sends (step d) a RAU Accept message with no active
NSAPI value indicated. The femto forwards (step e) this message. On receiving this
message, the user terminal also deactivates (step f) its PDP Context according to
section 4.7.5.1.3 of 3GPP Technical Specification 24-008 version 5.16.0 (2006-06).
PDP Context Deactivation, and Reactivation with a new NSAPI value, in the event of
a NSAPI "clash"
If the femto translates the NSAPI to a value which the user terminal then
requests in another PDP Context, the femto deactivates the existing PDP Context
involving that translation, and requests that the PDP Context is reactivated. An
example is shown in Figure 8.
As shown in Figure 8, the user terminal firstly sends (step a) to the femto an
Activate PDP Context request including NSAPI value of 5 and first Access Point
Name, and a first Transaction Identifier () . The femto stores the TI and IMSI
(which is known from previous connection establishment procedures (not shown)),
translates the NSAPI from 5 to 15 (step b), and forwards (step c) the amended
Activate PDP Context request to the SGSN. The SGSN replies with a Radio Access
Bearer (RAB) Assignment request including a Radio Access Bearer Identity (RAB ED)
equal to the NSAPI value, namely 15. The femto responds by forwarding (step e) a
Radio Bearer Setup message including a RAB ID equal to the translated NSAPI value
of 5. The SGSN then sends (step f) an Activate PDP Context accept message to the
femto, which the femto forwards (step g) to the user terminal.
Subsequently a further PDP Context is desired by the user terminal, for
example because a new service is required requiring a different access point network,
so the user terminal sends (step h) an Activate PDP Context Request including an
NSAPI which happens to be 15, (plus a second Access Point Name (APN2) and a
second Transaction Identifier (TI2)), therefore there is a problem as that NSAPI value
is already in use between the SGSN and femto. The femto identifies (step i) this
problem and responds by sending (step j ) a Deactivate PDP Context Request that
includes the first Transaction Identifier and includes an instruction to request
Reactivation. The user terminal responds by deactivating the PDP Context with
NSAPI of 5 and sending (step k) a Deactivate PDP Context Accept message to the
femto. The femto then sends (step ) to the SGSN a Deactivate PDP Context Request
that includes the first Transaction Identifier, which replies (step m) with a Deactivate
PDP Context Accept message.
The second requested PDP Context is then activated by the femto sending
(step o) to the SGSN an Activate PDP Context Request to the SGSN. This request
includes an NSAPI value of 13 (which has been translated by the femto from the value
15 selected by the user equipment) together with the second access point name and
second Transaction Identifier. Thereafter the femto stores the UvISI and Transaction
Identifier and thereafter translates (step p) the NSAPI value of 15 to/from the user
terminal to the NSAPI value 13 to/from the SGSN. The SGSN replies (step q) with an
Activate PDP Context Request Accept, which the femto receives and forwards (step r)
to the user terminal.
The femto is then ready to reactivate the original PDP Context where the
NSAPI between user terminal and femto is 5 but with a different selected translated
NSAPI value to use between the femto and SGSN. Specifically, the user terminal
sends (step s) to the femto an Activate PDP Context request including an NSAPI
value of 5 and first Access Point Name, and a first Transaction Identifier (TI) . The
femto stores the IMSI and TI and, in this example, translates the NSAPI from 5 to 14
(step t), and forwards (step u) the amended Activate PDP Context request to the
SGSN. The SGSN replies (step v) with a Radio Access Bearer (RAB) Assignment
request including a Radio Access Bearer Identity (RAB ED) equal to the NSAPI value,
namely 14. The femto responds by forwarding (step w) a Radio Bearer Setup message
including a RAB ED equal to the translated NSAPI value of 5. The SGSN then sends
(step x) an Activate PDP Context accept message to the femto, which the femto
forwards (step y) to the user terminal.
Some Variants
In some alternative embodiments, rather than the translation being performed
by the femto, the translation is performed by the femto-gateway.
In some embodiments, the femto network, more specifically the femto or
femto-gateway can perform NSAPI translation only on PDP Contexts that are
activated with a certain Access Point Name (APN) by determining the APN from the
Activate PDP Context request.
In some embodiments, NSAPI translation may be performed by any of the
cluster of femtos that share a femto-gateway. This may be instructed by the femtogateway,
or instructed by one femto informing another in the case of inter-femto
reselection/handover.
General
The present invention may be embodied in other specific forms without
departing from its essential characteristics. The described embodiments are to be
considered in all respects only as illustrative and not restrictive. The scope of the
invention is, therefore, indicated by the appended claims rather than by the foregoing
description. All changes that come within the meaning and range of equivalency of
the claims are to be embraced within their scope.
A person skilled in the art would readily recognize that steps of various abovedescribed
methods can be performed by programmed computers. Some embodiments
relate to program storage devices, e.g., digital data storage media, which are machine
or computer readable and encode machine-executable or computer-executable
programs of instructions, wherein said instructions perform some or all of the steps of
said above-described methods. The program storage devices may be, e.g., digital
memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard
drives, or optically readable digital data storage media. Some embodiments involve
computers programmed to perform said steps of the above-described methods.
Claims:
1. A method of deactivating Packet Data Protocol, PDP, Context upon transfer of a
connection with a user terminal between a femtocell base station and a macrocell base
station, the method comprising:
the femtocell base station receiving (Fig.3:a) a message including a first
identifier of a PDP Context, altering the identifier of the PDP Context to a second
identifier, and forwarding the altered message to the core network,
the core network receiving a further message including an identifier, the core
network determining that the received identifier does not match the identifier that the
core network expects and so deactivating the PDP Context.
2. A method according to claim 1, in which the first identifier of the PDP Context
is used in messaging between the user terminal and femtocell base station and the
second identifier which is an identifier of the PDP Context, is used in messaging
between the femtocell base station and core network, the method comprising
requesting (Fig.6:b) transfer of the connection to via macrocell base station by
forwarding from the macrocell base station to the core network said further message
which is a connection transfer request message including the first identifier;
the core network expecting the second identifier so deactivating the PDP
Context.
3. A method according to claim 1, comprising requesting (Fig.7:b) transfer of the
connection from via the macrocell base station to via the femtocell base station by
forwarding said further message which is a connection transfer request message
including the second identifier to the core network,
the core network expecting the first identifier so deactivating the PDP Context.
4. A method according to claim 3, in which the second identifier is an indication of
no Network Service Access Point Identifier, NSAPI.
5. A method according to any preceding claim in which the first identifier is an
NSAPI value and the second identifier is a different NSAPI value or indication of no
NSAPI.
6. A method according to any preceding claim, in which the femtocell base station
stores a mapping of the first identifier to the second identifier.
7. A method according to any preceding claim, in which the user terminal receives a
message including the second identifier but expects to receive the first identifier so
also deactivates the PDP Context.
8. A method according to any preceding claim, in which the connection transfer
request message is a routing area update request.
9. A method according to any preceding claim, in which upon the second identifier
having a value requested for use as an identifier by the user terminal, the PDP Context
associated with the first identifier is deactivated, so as to make the second identifier
value available for the requested use by the user terminal, and the PDP Context is
subsequently reactivated with a different second identifier value.
10. A method according to any preceding claim, in which the femtocell base station
is controlled by a femto-gateway and the femto-gateway controls altering the
identifier.
11. A method according to claim 10, in which upon reselection to another femtocell
base station in a cluster of femtocell base stations, said another femtocell base station
is informed of the second identifier for use in messages to the core network.
12. A method according to any preceding claim, in which the second identifier is
used only in respect of PDP Contexts having a selected Access Point Name, APN.
13. A telecommunications network comprising a femtocell base station, a macrocell
base station, and a core network, the femto base station being configured to receive a
message including a first identifier of a PDP Context, to alter the identifier of a PDP
Context to a second identifier, and to forward the altered message to the core network;
the core network being configured to receive a message including such an identifier,
to determine that the received identifier does not match the identifier that the core
network expects and so to deactivate the PDP Context.
14. A telecommunications network according to claim 13, in which the first
identifier of the PDP Context is used in messaging between a user terminal and
femtocell base station and the second identifier is used as the identifier of the PDP
Context in messaging between the femtocell base station and core network, the user
terminal being configured to request transfer of the connection to via macrocell base
station and the macrocell base station being configured to forward to the core
network the request message including the first identifier,
the core network being configured to expect the second identifier and so to
respond to the first identifier by deactivating the PDP Context.
15. A telecommunications network according to claim 13, comprising the user
terminal being configured to request transfer of the connection from via the macrocell
base station to via the femtocell base station, the femtocell base station being
configured to forward the request message including the second identifier to the core
network,
the core network being configured to expect the first identifier and so to
respond to reception of the second identifier by deactivating the PDP Context.

Documents

Application Documents

# Name Date
1 8797-CHENP-2012 POWER OF ATTORNEY 15-10-2012.pdf 2012-10-15
1 8797-CHENP-2012-RELEVANT DOCUMENTS [03-08-2023(online)].pdf 2023-08-03
2 8797-CHENP-2012 FORM-5 15-10-2012.pdf 2012-10-15
2 8797-CHENP-2012-RELEVANT DOCUMENTS [26-08-2022(online)].pdf 2022-08-26
3 8797-CHENP-2012-RELEVANT DOCUMENTS [18-09-2021(online)].pdf 2021-09-18
3 8797-CHENP-2012 FORM-3 15-10-2012.pdf 2012-10-15
4 8797-CHENP-2012-RELEVANT DOCUMENTS [23-03-2020(online)].pdf 2020-03-23
4 8797-CHENP-2012 FORM-2 FIRST PAGE 15-10-2012.pdf 2012-10-15
5 8797-CHENP-2012-IntimationOfGrant30-05-2019.pdf 2019-05-30
5 8797-CHENP-2012 FORM-18 15-10-2012.pdf 2012-10-15
6 8797-CHENP-2012-PatentCertificate30-05-2019.pdf 2019-05-30
6 8797-CHENP-2012 FORM-1 15-10-2012.pdf 2012-10-15
7 Abstract_Granted 313441_30-05-2019.pdf 2019-05-30
7 8797-CHENP-2012 DRAWINGS 15-10-2012.pdf 2012-10-15
8 Claims_Granted 313441_30-05-2019.pdf 2019-05-30
8 8797-CHENP-2012 DESCRIPTION (COMPLETE) 15-10-2012.pdf 2012-10-15
9 8797-CHENP-2012 CORRESPONDENCE OTHERS 15-10-2012.pdf 2012-10-15
9 Description_Granted 313441_30-05-2019.pdf 2019-05-30
10 8797-CHENP-2012 CLAIMS SIGNATURE LAST PAGE 15-10-2012.pdf 2012-10-15
10 Drawings_Granted 313441_30-05-2019.pdf 2019-05-30
11 8797-CHENP-2012 CLAIMS 15-10-2012.pdf 2012-10-15
11 Marked Up Claims_Granted 313441_30-05-2019.pdf 2019-05-30
12 8797-CHENP-2012 PCT PUBLICATION 15-10-2012.pdf 2012-10-15
12 Correspondence by Agent_Notarized Assignment_09-05-2019.pdf 2019-05-09
13 8797-CHENP-2012-ABSTRACT [08-05-2019(online)].pdf 2019-05-08
13 8797-CHENP-2012.pdf 2012-10-17
14 8797-CHENP-2012 FORM-3 09-04-2013.pdf 2013-04-09
14 8797-CHENP-2012-CLAIMS [08-05-2019(online)].pdf 2019-05-08
15 8797-CHENP-2012 CORRESPONDENCE OTHERS 09-04-2013.pdf 2013-04-09
15 8797-CHENP-2012-COMPLETE SPECIFICATION [08-05-2019(online)].pdf 2019-05-08
16 8797-CHENP-2012 FORM-3 19-06-2013.pdf 2013-06-19
16 8797-CHENP-2012-FER_SER_REPLY [08-05-2019(online)].pdf 2019-05-08
17 8797-CHENP-2012-FORM 3 [08-05-2019(online)].pdf 2019-05-08
17 8797-CHENP-2012 CORRESPONDENCE OTHERS 19-06-2013.pdf 2013-06-19
18 8797-CHENP-2012 FORM-3 17-10-2013.pdf 2013-10-17
18 8797-CHENP-2012-OTHERS [08-05-2019(online)].pdf 2019-05-08
19 8797-CHENP-2012 CORRESPONDENCE OTHERS 17-10-2013.pdf 2013-10-17
19 8797-CHENP-2012-PETITION UNDER RULE 137 [08-05-2019(online)].pdf 2019-05-08
20 8797-CHENP-2012-Proof of Right (MANDATORY) [08-05-2019(online)].pdf 2019-05-08
20 abstract8797-CHENP-2012.jpg 2014-01-07
21 8797-CHENP-2012 FORM-3 13-08-2014.pdf 2014-08-13
21 8797-CHENP-2012-FORM 4(ii) [15-02-2019(online)].pdf 2019-02-15
22 8797-CHENP-2012 CORRESPONDENCE OTHERS 13-08-2014.pdf 2014-08-13
22 8797-CHENP-2012-FER.pdf 2018-08-28
23 8797-CHENP-2012 CORRESPONDENCE OTHERS 20-10-2014.pdf 2014-10-20
23 8797-CHENP-2012-Correspondence-F3-290216.pdf 2016-07-04
24 8797-CHENP-2012-Form 3-290216.pdf 2016-07-04
24 8797-CHENP-2012 FORM-3 20-10-2014.pdf 2014-10-20
25 8797-CHENP-2012 CORRESPONDENCE OTHERS 03-03-2015.pdf 2015-03-03
25 8797-CHENP-2012-CORRESPONDENCE-15-10-15.pdf 2016-03-19
26 8797-CHENP-2012 FORM-3 03-03-2015.pdf 2015-03-03
26 8797-CHENP-2012-FORM-3-15-10-15.pdf 2016-03-19
27 8797-CHENP-2012 FORM-3 03-03-2015.pdf 2015-03-03
27 8797-CHENP-2012-FORM-3-15-10-15.pdf 2016-03-19
28 8797-CHENP-2012 CORRESPONDENCE OTHERS 03-03-2015.pdf 2015-03-03
28 8797-CHENP-2012-CORRESPONDENCE-15-10-15.pdf 2016-03-19
29 8797-CHENP-2012 FORM-3 20-10-2014.pdf 2014-10-20
29 8797-CHENP-2012-Form 3-290216.pdf 2016-07-04
30 8797-CHENP-2012 CORRESPONDENCE OTHERS 20-10-2014.pdf 2014-10-20
30 8797-CHENP-2012-Correspondence-F3-290216.pdf 2016-07-04
31 8797-CHENP-2012 CORRESPONDENCE OTHERS 13-08-2014.pdf 2014-08-13
31 8797-CHENP-2012-FER.pdf 2018-08-28
32 8797-CHENP-2012 FORM-3 13-08-2014.pdf 2014-08-13
32 8797-CHENP-2012-FORM 4(ii) [15-02-2019(online)].pdf 2019-02-15
33 8797-CHENP-2012-Proof of Right (MANDATORY) [08-05-2019(online)].pdf 2019-05-08
33 abstract8797-CHENP-2012.jpg 2014-01-07
34 8797-CHENP-2012 CORRESPONDENCE OTHERS 17-10-2013.pdf 2013-10-17
34 8797-CHENP-2012-PETITION UNDER RULE 137 [08-05-2019(online)].pdf 2019-05-08
35 8797-CHENP-2012 FORM-3 17-10-2013.pdf 2013-10-17
35 8797-CHENP-2012-OTHERS [08-05-2019(online)].pdf 2019-05-08
36 8797-CHENP-2012-FORM 3 [08-05-2019(online)].pdf 2019-05-08
36 8797-CHENP-2012 CORRESPONDENCE OTHERS 19-06-2013.pdf 2013-06-19
37 8797-CHENP-2012 FORM-3 19-06-2013.pdf 2013-06-19
37 8797-CHENP-2012-FER_SER_REPLY [08-05-2019(online)].pdf 2019-05-08
38 8797-CHENP-2012 CORRESPONDENCE OTHERS 09-04-2013.pdf 2013-04-09
38 8797-CHENP-2012-COMPLETE SPECIFICATION [08-05-2019(online)].pdf 2019-05-08
39 8797-CHENP-2012 FORM-3 09-04-2013.pdf 2013-04-09
39 8797-CHENP-2012-CLAIMS [08-05-2019(online)].pdf 2019-05-08
40 8797-CHENP-2012-ABSTRACT [08-05-2019(online)].pdf 2019-05-08
40 8797-CHENP-2012.pdf 2012-10-17
41 8797-CHENP-2012 PCT PUBLICATION 15-10-2012.pdf 2012-10-15
41 Correspondence by Agent_Notarized Assignment_09-05-2019.pdf 2019-05-09
42 8797-CHENP-2012 CLAIMS 15-10-2012.pdf 2012-10-15
42 Marked Up Claims_Granted 313441_30-05-2019.pdf 2019-05-30
43 8797-CHENP-2012 CLAIMS SIGNATURE LAST PAGE 15-10-2012.pdf 2012-10-15
43 Drawings_Granted 313441_30-05-2019.pdf 2019-05-30
44 8797-CHENP-2012 CORRESPONDENCE OTHERS 15-10-2012.pdf 2012-10-15
44 Description_Granted 313441_30-05-2019.pdf 2019-05-30
45 8797-CHENP-2012 DESCRIPTION (COMPLETE) 15-10-2012.pdf 2012-10-15
45 Claims_Granted 313441_30-05-2019.pdf 2019-05-30
46 Abstract_Granted 313441_30-05-2019.pdf 2019-05-30
46 8797-CHENP-2012 DRAWINGS 15-10-2012.pdf 2012-10-15
47 8797-CHENP-2012-PatentCertificate30-05-2019.pdf 2019-05-30
47 8797-CHENP-2012 FORM-1 15-10-2012.pdf 2012-10-15
48 8797-CHENP-2012-IntimationOfGrant30-05-2019.pdf 2019-05-30
48 8797-CHENP-2012 FORM-18 15-10-2012.pdf 2012-10-15
49 8797-CHENP-2012-RELEVANT DOCUMENTS [23-03-2020(online)].pdf 2020-03-23
49 8797-CHENP-2012 FORM-2 FIRST PAGE 15-10-2012.pdf 2012-10-15
50 8797-CHENP-2012-RELEVANT DOCUMENTS [18-09-2021(online)].pdf 2021-09-18
50 8797-CHENP-2012 FORM-3 15-10-2012.pdf 2012-10-15
51 8797-CHENP-2012 FORM-5 15-10-2012.pdf 2012-10-15
51 8797-CHENP-2012-RELEVANT DOCUMENTS [26-08-2022(online)].pdf 2022-08-26
52 8797-CHENP-2012 POWER OF ATTORNEY 15-10-2012.pdf 2012-10-15
52 8797-CHENP-2012-RELEVANT DOCUMENTS [03-08-2023(online)].pdf 2023-08-03

Search Strategy

1 search_14-08-2018.pdf

ERegister / Renewals

3rd: 26 Aug 2019

From 01/03/2013 - To 01/03/2014

4th: 26 Aug 2019

From 01/03/2014 - To 01/03/2015

5th: 26 Aug 2019

From 01/03/2015 - To 01/03/2016

6th: 26 Aug 2019

From 01/03/2016 - To 01/03/2017

7th: 26 Aug 2019

From 01/03/2017 - To 01/03/2018

8th: 26 Aug 2019

From 01/03/2018 - To 01/03/2019

9th: 26 Aug 2019

From 01/03/2019 - To 01/03/2020

10th: 26 Aug 2019

From 01/03/2020 - To 01/03/2021

11th: 05 Feb 2021

From 01/03/2021 - To 01/03/2022

12th: 02 Feb 2022

From 01/03/2022 - To 01/03/2023