Abstract: An SeNB (30) informs an MeNB (20) that it can configure bearers for the given UE (10). At this time the MeNB (20) manages the DRB status and then sends a key S KeNB to the SeNB (30). The MeNB (20) also sends a KSI for the S KeNB to both of the UE (10) and the SeNB (30). After this procedure the MeNB (20) informs an EPC (MME (40) and S GW (50)) about the new bearer configured at the SeNB (30) such that the S GW 50 can start offloading the bearer(s) to the SeNB 30. Prior to the offloading the EPC network entity (MME (40) or S GW (50)) performs verification that: 1) whether the request is coming from authenticated source (MeNB); and 2) whether the SeNB (30) is a valid eNB to which the traffic can be offload.
Description
Title of Invention:
APPARATUS, SYSTEM AND METHOD FOR
SMALL CELL ENHANCEMENT / DUAL CONNECTIVITY
Technical Field
[0001] The present invention relates to an apparatus, a system and a method for SCE (Small
Cell Enhancement) or DC (Dual Connectivity), and particularly to a technique to
secure SeNB (Secondary eNB (evolved Node B)) Addition/Modification procedure in
order to provide security in dual connectivity for the given UE (User Equipment).
Background Art
[0002] The SCE or DC was defined in 3GPP (3rd Generation Partnership Project) RAN
(Radio Access Network) working groups, and it has initiated a study on security aspect
and impact on the architecture 1A defined in NPL 1.
[0003] For user plane data transmission between UE and SeNB, a new key for the confi
dentiality protection is needed. The RRC (Radio Resource Control) signaling
terminates in the MeNB (Master eNB), thus it is responsible for the key management.
[0004] In current architecture disclosed in NPL 1, each UE is connected to one MeNB and
one SeNB. There can be multiple bearers between SeNB and UE. The key for UE and
SeNB user plane communication protection, denoted as S-KUPenc, is derived at SeNB
and UE from a key S-KeNB shared between UE and SeNB. The S-KeNB is derived at
MeNB and sent to SeNB. UE derives the same S-KeNB at its side.
Citation List
Non Patent Literature
[0005] NPL 1: 3GPP TR 36.842, "Study on Small Cell enhancements for E-UTRA and EUTRAN;
Higher layer aspects (Release 12)", V12.0.0, 2013-12
NPL 2: S3-14021 1, 3GPP TSG SA WG3 (Security) Meeting #74
NPL 3: S3-140209, 3GPP TSG SA WG3 (Security) Meeting #74
NPL 4: S3-140210, 3GPP TSG SA WG3 (Security) Meeting #74
Summary of Invention
Technical Problem
[0006] However, the inventors of this application have found that in the current solution,
there are the following problems a) to c).
a) The key S-KeNB is sent in SeNB "Addition/Modification Request" as disclosed in
NPLs 2 to 4. That is, the key S-KeNB is sent before SeNB is configured. Consider
when a SeNB rejects the configuration (due to its capability or some other reason), or
the configuration fails, the MeNB has to derive a new S-KeNB for the next SeNB it
attempts to configure, meanwhile increases the counter.
b) There is no information of SeNB DRB (Data Radio Bearer) configuration at MeNB.
This may cause improper key derivation and management, i.e., whether a new key SKeNB
should be derived when a new DRB is configured in SeNB.
c) S-KeNB identity: SeNB may serve more than one UEs, and UE may connect to
more than one SeNBs at different times or at same time (potential future architecture),
giving a KSI (Key Set Identifier) can ensure UE and SeNB identify the key.
[0007] Accordingly, an exemplary object of the present invention is to provide a solution for
solving at least one of the above-mentioned problems.
Solution to Problem
[0008] In order to achieve the above-mentioned object, each of an apparatus, a system and a
method according to exemplary aspects of the present invention gives more details on:
1) Optimized SeNB Addition/Modification procedure based on security: key
derivation and allocation; and
2) Secure SeNB Addition/Modification.
[0009] According to first exemplary aspect of the present invention, there is provided a
mobile communication system for dual connectivity. This mobile communication
system includes: a first Node B; a second Node B; a mobility management apparatus;
and a gateway. The first Node B sends a Modification Indication message including in
formation on dual connectivity or information on the second Node B to the mobility
management apparatus. The mobility management apparatus sends a Modify Bearer
Request message including the information on dual connectivity or the information on
the second Node B to the gateway.
[0010] According to second exemplary aspect of the present invention, there is provided a
communication method for dual connectivity having a first Node B and a second Node
B. This communication method includes: sending a Modification Indication message
including information on dual connectivity or information on the second Node B from
the first Node B to a mobility management apparatus; and sending a Modify Bearer
Request message including the information on dual connectivity or the information on
the second Node B from the mobility management apparatus to a gateway.
[001 1] According to third exemplary aspect of the present invention, there is provided a base
station used in dual connectivity. This base station includes: sending means for sending
a Modification Indication message including information on dual connectivity or in
formation on a second base station for dual connectivity to a mobility management
apparatus; and receiving means for receiving a Modification Confirmation message
from the mobility management apparatus.
[0012] According to fourth exemplary aspect of the present invention, there is provided a
mobility management apparatus used in dual connectivity. This mobility management
apparatus includes: receiving means for receiving a Modification Indication message
including information on dual connectivity or information on a second Node B from a
first Node B; and sending means for sending a Modify Bearer Request message
including the information on dual connectivity or the information on the second Node
B to a gateway.
Advantageous Effects of Invention
[0013] According to the present invention, it is possible to solve at least one of the abovementioned
problems.
Brief Description of Drawings
[0014] [fig.l]Fig. 1 is a block diagram showing a configuration example of a system
according to an exemplary embodiment of the present invention.
[fig.2]Fig. 2 is a sequence diagram showing an example of optimized SeNB Addition/
Modification procedure in the system according to the exemplary embodiment.
[fig.3]Fig. 3 is a sequence diagram showing a first example of bearer modification and
SeNB verification at S-GW in the system according to the exemplary embodiment.
[fig.4]Fig. 4 is a sequence diagram showing a second example of bearer modification
and SeNB verification at S-GW in the system according to the exemplary embodiment.
[fig.5]Fig. 5 is a sequence diagram showing a third example of bearer modification and
SeNB verification at S-GW in the system according to the exemplary embodiment
[fig.6]Fig. 6 is a block diagram showing a configuration example of an MeNB
according to the exemplary embodiment.
[fig.7]Fig. 7 is a block diagram showing a configuration example of an MME
according to the exemplary embodiment.
Description of Embodiments
[0015] Hereinafter, an exemplary embodiment of an apparatus, a system and a method
according to the present invention, will be described with the accompanying drawings.
[0016] Fig. 1 shows a configuration example of a system according to this exemplary em
bodiment, taking as an example the architecture where there is one SeNB per UE.
[0017] This system includes a UE 10, an MeNB 20, an SeNB 30, an MME (Mobility
Management Entity) 40, and an S-GW (Serving Gateway) 50. Note that although the
illustration is omitted in Fig. 1, the system also includes a P-GW (PDN (Public Data
Network) Gateway) 60 as shown in Figs. 4 to 6.
[0018] As shown by solid lines in Fig. 1, there are provided several interfaces for C-Plane
(Control-Plane) signaling. The UE 10 communicates with the MeNB 20 through a Uu
interface. The MeNB 20 communicates with the SeNB 30 through an X2-C interface,
and communicates with the MME 40 through an SI-MME interface. The SI-MME
interface does not exist between the SeNB 30 and the MME 40.
[0019] Further, as shown by dotted lines in Fig. 1, there are also provided several interfaces
for U-Plane (User-Plane) communication. Each of the MeNB 20 and the SeNB 30
communicates with the S-GW 50 through an Sl-U interface. In this architecture, UPlane
traffic between the UE 10 and the S-GW 50 is transmitted through the MeNB 20
and the SeNB 30 in parallel for the purpose of offloading the MeNB 20 (in other
words, for the purpose of offloading the backhaul Sl-U interface between the MeNB
20 and the S-GW 50). Moreover, one or more bearers DRB1 to DRBn are established
between the UE 10 and the SeNB 30.
[0020] Next, there will be described operation examples of this exemplary embodiment with
reference to Figs. 2 to 5.
[0021] 1. Optimized SeNB Addition/Modification procedure
To counter the problems a) to c) given above, this exemplary embodiment proposes
that:
- S-KeNB is sent after step S4 "SeNB Addition/Modification Command" shown in
Fig. 2. At step S4, the SeNB 30 informs that it can configure bearers for the given UE
10.
- The MeNB 20 manages the DRB status.
- The MeNB 20 sends KSI to both of the UE 10 and the SeNB 30.
[0022] Fig. 2 is based on the scenario disclosed in NPL 1 that there is only one MeNB and
SeNB per UE. Note that processes at step S4, S6 and S7 are novel part in this
invention.
[0023] New step/parameter in key derivation and allocation are as follows.
[0024] Step S4: The SeNB 30 sends to the MeNB 20 its capabilities, if it is different from
standard. The capabilities of the SeNB 30 are included in SeNB Addition/Modification
Command.
[0025] Step S6: The MeNB 20 sends the S-KeNB and KSI after receiving the SeNB
Addition/Modification Command. A new message for sending the S-KeNB and the
KSI can be defined as Key Update.
[0026] The reason for performing this step is: reduce the counter value usage. If the MeNB
20 sends the S-KeNB in the SeNB Addition/Modification Request at step S2, and the
SeNB 30 does not have radio resource for the UE 10, the MeNB 20 will have to derive
a new key and send to next SeNB till it finds the capable SeNB.
[0027] Step S7: the MeNB 20 sends a KSI of S-KeNB to the UE 10 with the counter. This is
to make sure that the UE 10 will use the same key as the SeNB 30.
[0028] 2. Authorization of MeNB and SeNB
After the SeNB Addition/Modification procedure, the "update of the UP path towards
the EPC is performed" as described in NPL 1. The MeNB 20 should inform the MME
40 and the S-GW 50 about the new bearer configured at the SeNB 30, such that the SGW
50 can start offloading the bearer(s) to the SeNB 30.
[0029] Before doing the offloading, the network entity (MME 40 or S-GW 50) should
perform verification that: 1) whether the request is coming from authenticated source
(MeNB); and 2) whether SeNB is a valid eNB to which the traffic can be offload. The
network entity (MME 40 or S-GW 50) can be pre-configured with information for the
verification, or it can interact with another entity requesting for verification.
[0030] In order to offload the traffic to the correct SeNB 30, the S-GW 50 needs to know
that there is offload bearer configured in the SeNB 30 and traffic from the SeNB 30 to
the UE 10, on top of SeNB ID (identity) & IP (Internet Protocol) address. Therefore,
the SeNB 30 or the MeNB 20 should indicate the DC configuration information
(contains the configured DRB information, SeNB ID and SeNB IP address) to the SGW
50, such that the S-GW 50 knows that dual connectivity is being activated and a
new bearer is added to the SeNB 30, and the S-GW 50 should not release the bearer in
the MeNB 20. The MME 40 should also be informed that dual connectivity is being
activated, such that it can behave accordingly including forwarding the S-GW 50 the
information and should not behave same as in handover procedure when Path Switch
Request message is received from the MeNB 20.
[0031] Figs. 3 to 5 show alternatives 1 to 3 for the bearer modification and SeNB veri
fication at the S-GW 50, respectively.
[0032] Alternative 1>
This alternative follows the current procedure in NPL 1, Figure G.l-1, Steps 11-13.
The changes are given below:
[0033] At step S11 shown in Fig. 3, the MeNB 20 informs the MME 40 about newly
configured SeNB and DRB, includes 1) DC configuration information (contains the
configured DRB information, SeNB ID and SeNB IP address), and 2) indicator to
show this is for DC. The MME 40 can forward the S-GW 50 the information in Step
S12.
[0034] Step S12: The MME 40 sends bearer modification to the S-GW 50 indicating that
this is a DC case together with information that the given DRB of a UE should be sent
to the SeNB 30.
[0035] The network entity (MME 40 or S-GW 50) verifies: 1) whether the MeNB 20 is
allowed to configure the SeNB 30 for the given UE 10; 2) whether the SeNB 30 is a
valid network element; and 3) whether the SeNB 30 is authorized to provide dual con
nectivity. When the verification is done at the MME 40, it should be after the MME 40
receives Step SI 1 message. When the verification is done at the S-GW 50, it can
happen after it receives the message from the MME 40.
[0036] Alternative 2>
The procedure uses Path Switch procedure as indicated in Gl of NPL 1. Note that it is
initiated by the MeNB 20.
[0037] At step S21 shown in Fig. 4, the MeNB 20 sends Path Switch Request message to the
MME 40, includes 1) DC configuration information (contains the configured DRB in
formation, SeNB ID and SeNB IP address), and 2) indicator to show this is for DC.
This is to inform that there is a new bearer from a SeNB has been configured not that
UE has changed cell in handover procedure.
[0038] Step S22: When the MME 40 receives Path Switch Request, it determines whether
this message is for DC or handover. If it is for DC, it will not compute NH (Next Hop)
and not increase the NCC (Next-hop Chaining Counter) value it keeps. The MME 40
then sends Modify Bearer Request message to the S-GW 50, includes the DC con
figuration information (contains the configured DRB information, SeNB ID and SeNB
IP address) it received above.
[0039] Step S23: The S-GW 50 sends Modify Bearer Response to the MME 40, if the veri
fication is successfully completed.
[0040] Step S24: The MME 40 sends Path Switch Request Ack (Acknowledgement) to the
MeNB 20. The MME 40 should include an indicator to inform the MeNB 20 this is for
DC. The MME 40 should not include any NCC value in this message since this is not
for handover.
[0041] Step S25: The S-GW 50 and the P-GW 60 exchange the Modify Bearer Request/
Response messages.
[0042] Step S26: The P-GW 60 starts Downlink data.
[0043] The network entity (MME 40 or S-GW 50) should perform the verification as in Al
ternative 1.
[0044] Alternative 3>
The procedure also uses Path Switch procedure as indicated in Gl of NPL 1. Note
that it is initiated by the SeNB 30.
[0045] At steps S31-S32 shown in Fig. 5, the SeNB 30 sends Path Switch Request message
to the MME 40 via the MeNB 20, includes 1) DC configuration information (contains
the configured DRB information, SeNB ID and SeNB IP address), and 2) indicator to
show this is for DC. This is to inform that there is a new bearer from a SeNB has been
configured not that UE has changed cell in handover procedure.
[0046] Step S33: When the MME 40 receives Path Switch Request, it determines whether
this message is for DC or handover. If it is for DC, it will not compute NH and not
increase the NCC value it keeps. The MME 40 then sends Modify Bearer Request
message to the S-GW 50, includes the DC configuration information (contains the
configured DRB information, SeNB ID and SeNB IP address) it received above.
[0047] Step S34: The S-GW 50 sends Modify Bearer Response to the MME 40, if the verification
is successfully completed.
[0048] Steps S35-S36: The MME 40 sends Path Switch Request Ack to the SeNB 30 via the
MeNB 20. The MME 40 should include an indicator to inform the MeNB 20 this is for
DC. The MME 40 should not include any NCC value in this message since this is not
for handover.
[0049] Step S37: The S-GW 50 and the P-GW 60 exchange the Modify Bearer Request/
Response messages.
[0050] Step S38: The P-GW 60 starts Downlink data.
[005 1] The network entity (MME 40 or S-GW 50) should perform the verification as in Al
ternative 1.
[0052] Next, there will be described configuration examples of the MeNB 20 and the MME
40 with reference to Figs. 6 and 7, respectively.
[0053] As shown in Fig. 6, the MeNB 20 includes a sending unit 2 1 and a receiving unit 22.
The sending unit 2 1 sends, to the MME 40, the E-RAB Modification Indication
message as shown at step SI 1 in Fig. 3, which includes the DC configuration in
formation and/or the indicator. The receiving unit 22 receives, from the MME 40, the
E-RAB Modification Confirmation message as shown at step S13 in Fig. 3. Note that
these units 2 1 and 22 as well as other element(s) of the MeNB 20 can be implemented
by at least hardware such as a transceiver which conducts communication with the
SeNB 30, the MME 40 and the S-GW 50, a transceiver which conducts wireless com
munication with the UE 10, as well as a controller like a CPU (Central Processing
Unit) which control these transceivers to execute the processes shown in each of Figs.
2 to 5 or processes equivalent thereto. The MeNB 20 can also be implemented by the
combination of such hardware, and software (e.g., a program as stored in a memory
and executed by the CPU).
[0054] As shown in Fig. 7, the MME 40 includes at least a receiving unit 4 1 and a sending
unit 42. The receiving unit 4 1 receives, from the MeNB 20, the E-RAB Modification
Indication message including the DC configuration information and/or the indicator.
The sending unit 42 sends, to the S-GW 50, the Modify Bearer Request message as
shown at step S22 in Fig. 4, which includes the DC configuration information and/or
the indicator. The sending unit 42 may be further configured to send the E-RAB Modi
fication Confirmation message to the MeNB 20. The MME 40 may further include a
verifying unit 43. The verifying unit 43 is triggered by the E-RAB Modification In
dication message to verify the MeNB 20 and the SeNB 30 for the dual connectivity, as
mentioned above. Alternatively, the Modify Bearer Request message may trigger the
S-GW 50 to perform such verification. Note that these units 4 1 to 43 as well as other
element(s) of the MME 40 can be implemented by at least hardware such as a
transceiver which conducts communication with the MeNB 20 and the S-GW 50, as
well as a controller like a CPU which control this transceiver to execute the processes
shown in each of Figs. 2 to 5 or processes equivalent thereto. The MME 40 can also be
implemented by the combination of such hardware, and software (e.g., a program as
stored in a memory and executed by the CPU).
[0055] Note that the present invention is not limited to the above-mentioned exemplary em
bodiment, and it is obvious that various modifications can be made by those of
ordinary skill in the art based on the recitation of the claims.
[0056] The whole or part of the exemplary embodiment disclosed above can be described as,
but not limited to, the following supplementary notes.
[0057] (Supplementary note 1)
An MeNB that sends out a key S-KeNB after reception of "SeNB Addition/Mod
ification Command", thereby to:
1) prevent the S-KeNB being maliciously used by an SeNB that received but the
bearer will not be configured for a given UE; and/or
2) prevent increase of counter value.
[0058] (Supplementary note 2)
An MeNB that sends S-KeNB identity to both of an SeNB and a UE.
[0059] (Supplementary note 3)
A system that re-uses a Path Switch Request message to inform an EPC (MME and/
or S-GW) about the SeNB/ new bearer configuration.
[0060] (Supplementary note 4)
An S-GW that verifies whether an MeNB and an SeNB are authorized to carry the
dual connectivity.
[006 1] (Supplementary note 5)
A system, wherein Path Switch procedure is updated for DC that it contains:
1) DC configuration information (contains the configured DRB information, SeNB
ID and SeNB IP address); and
2) indicator to show this is for DC.
[0062] (Supplementary note 6)
A system, wherein an MME and an S-GW behavior in this procedure are updated for
dual connectivity that:
1) the MME will not compute NH and not increase the NCC value it keeps;
2) the MME should include an indicator to inform an MeNB the Path Switch Request
Ack message is for DC;
3) the MME should not include any NCC value in Path Switch Request Ack message
since this is not for handover; and/or
4) the S-GW will not release the bearer in the MeNB as in handover procedure.
[0063] This application is based upon and claims the benefit of priority from Japanese patent
application No. 2014-043929 filed on March 6, 2014, the disclosures of which is in
corporated herein in its entirety by reference.
Reference Signs List
10 UE
20 MeNB
21, 42 SENDING UNIT
22, 4 1 RECEIVING UNIT
43 VERIFYING UNIT
30 SeNB
40 MME
50 S-GW
60 P-GW
Claims
A mobile communication system for dual connectivity, comprising:
a first Node B;
a second Node B;
a mobility management apparatus; and
a gateway,
wherein:
the first Node B sends a Modification Indication message including in
formation on dual connectivity or information on the second Node B to
the mobility management apparatus; and
the mobility management apparatus sends a Modify Bearer Request
message including the information on dual connectivity or the in
formation on the second Node B to the gateway.
The mobile communication system according to Claim 1, wherein
the mobility management apparatus sends a Modification Confirmation
message to the first Node B.
The mobile communication system according to Claim 1 or 2, wherein
the gateway sends a Modify Bearer Response to the mobility
management apparatus.
The mobile communication system according to any one of Claims 1 to
3, wherein:
the mobility management apparatus is triggered by the Modification In
dication message to verify the first Node B and the second Node B for
the dual connectivity; or
the gateway is triggered by the Modify Bearer Request message to
perform the verification.
The mobile communication system according to any one of Claims 1 to
4,
wherein the first Node B comprises an MeNB (Master evolved Node
B), the second Node B comprises an SeNB (Secondary evolved Node
B), the mobility management apparatus comprises an MME (Mobility
Management Entity), and the gateway comprises an SGW (Serving
Gateway).
The mobile communication system according to any one of Claims 1 to
5,
wherein the Modification Indication message comprises an E-RAB
(E-UTRAN (Evolved Universal Terrestrial Radio Access Network)
PCT/JP2015/001164
Radio Access Bearer) Modification Indication message, and the Modi
fication Confirmation message comprises an E-RAB Modification Con
firmation message.
A communication method for dual connectivity having a first Node B
and a second Node B, the communication method comprising:
sending a Modification Indication message including information on
dual connectivity or information on the second Node B from the first
Node B to a mobility management apparatus; and
sending a Modify Bearer Request message including the information on
dual connectivity or the information on the second Node B from the
mobility management apparatus to a gateway.
The communication method according to Claim 7, further comprising:
sending a Modification Confirmation message from the mobility
management apparatus to the first Node B.
The communication method according to Claim 7 or 8, further
comprising:
sending a Modify Bearer Response from the gateway to the mobility
management apparatus.
The communication method according to any one of Claims 7 to 9,
wherein:
the Modification Indication message triggers the mobility management
apparatus to verify the first Node B and the second Node B for the dual
connectivity; or
the Modify Bearer Request message triggers the gateway to perform
the verification.
The communication method according to any one of Claims 7 to 10,
wherein the first Node B comprises an MeNB (Master evolved Node
B), the second Node B comprises an SeNB (Secondary evolved Node
B), the mobility management apparatus comprises an MME (Mobility
Management Entity), and the gateway comprises an SGW (Serving
Gateway).
The communication method according to any one of Claims 7 to 11,
wherein the Modification Indication message comprises an E-RAB
(E-UTRAN (Evolved Universal Terrestrial Radio Access Network)
Radio Access Bearer) Modification Indication message, and the Modi
fication Confirmation message comprises an E-RAB Modification Con
firmation message.
A base station used in dual connectivity, comprising:
PCT/JP2015/001164
sending means for sending a Modification Indication message
including information on dual connectivity or information on a second
base station for dual connectivity to a mobility management apparatus;
and
receiving means for receiving a Modification Confirmation message
from the mobility management apparatus.
The base station according to Claim 13, wherein
the base station comprises an evolved Node B.
The base station according to Claim 13 or 14,
wherein the base station comprises an MeNB (Master evolved Node B),
the second base station comprises an SeNB (Secondary evolved Node
B), and the mobility management apparatus comprises an MME
(Mobility Management Entity).
The base station according to any one of Claims 13 to 15,
wherein the Modification Indication message comprises an E-RAB
(E-UTRAN (Evolved Universal Terrestrial Radio Access Network)
Radio Access Bearer) Modification Indication message, and the Modi
fication Confirmation message comprises an E-RAB Modification Con
firmation message.
A mobility management apparatus used in dual connectivity,
comprising:
receiving means for receiving a Modification Indication message
including information on dual connectivity or information on a second
Node B from a first Node B; and
sending means for sending a Modify Bearer Request message including
the information on dual connectivity or the information on the second
Node B to a gateway.
The mobility management apparatus according to Claim 17, wherein
the sending means is further configured to send a Modification Con
firmation message to the first Node B.
The mobility management apparatus according to Claim 17 or 18,
further comprising:
verifying means for being triggered by the Modification Indication
message to verify the first Node B and the second Node B for the dual
connectivity.
The mobility management apparatus according to any one of Claims 17
to 19, wherein
the mobility management apparatus comprises an MME (Mobility
WO 2015/133144 PCT/JP2015/001164
Management Entity).
[Claim 21] The mobility management apparatus according to any one of Claims 17
to 20,
wherein the first Node B comprises an MeNB (Master evolved Node
B), the second Node B comprises an SeNB (Secondary evolved Node
B), and the gateway comprises an SGW (Serving Gateway).
[Claim 22] The mobility management apparatus according to any one of Claims 17
to 21,
wherein the Modification Indication message comprises an E-RAB
(E-UTRAN (Evolved Universal Terrestrial Radio Access Network)
Radio Access Bearer) Modification Indication message, and the Modi
fication Confirmation message comprises an E-RAB Modification Con
firmation message.
| Section | Controller | Decision Date |
|---|---|---|
| # | Name | Date |
|---|---|---|
| 1 | Priority Document [04-10-2016(online)].pdf | 2016-10-04 |
| 2 | Power of Attorney [04-10-2016(online)].pdf | 2016-10-04 |
| 3 | Form 5 [04-10-2016(online)].pdf | 2016-10-04 |
| 4 | Form 3 [04-10-2016(online)].pdf | 2016-10-04 |
| 5 | Form 18 [04-10-2016(online)].pdf_19.pdf | 2016-10-04 |
| 6 | Form 18 [04-10-2016(online)].pdf | 2016-10-04 |
| 7 | Drawing [04-10-2016(online)].pdf | 2016-10-04 |
| 8 | Description(Complete) [04-10-2016(online)].pdf | 2016-10-04 |
| 9 | 201617033930.pdf | 2016-10-13 |
| 10 | 201617033930-Power of Attorney-141016.pdf | 2016-10-18 |
| 11 | 201617033930-Correspondence-141016.pdf | 2016-10-18 |
| 12 | Marked Copy [01-11-2016(online)].pdf | 2016-11-01 |
| 13 | Form 13 [01-11-2016(online)].pdf | 2016-11-01 |
| 14 | Description(Complete) [01-11-2016(online)].pdf | 2016-11-01 |
| 15 | abstract.jpg | 2016-12-30 |
| 16 | Other Patent Document [12-01-2017(online)].pdf | 2017-01-12 |
| 17 | 201617033930-OTHERS-170117.pdf | 2017-01-19 |
| 18 | 201617033930-Correspondence-170117.pdf | 2017-01-19 |
| 19 | Form 3 [03-04-2017(online)].pdf | 2017-04-03 |
| 20 | 201617033930-OTHERS [10-11-2020(online)].pdf | 2020-11-10 |
| 21 | 201617033930-Information under section 8(2) [10-11-2020(online)].pdf | 2020-11-10 |
| 22 | 201617033930-FORM-26 [10-11-2020(online)].pdf | 2020-11-10 |
| 23 | 201617033930-FORM 3 [10-11-2020(online)].pdf | 2020-11-10 |
| 24 | 201617033930-FER_SER_REPLY [10-11-2020(online)].pdf | 2020-11-10 |
| 25 | 201617033930-DRAWING [10-11-2020(online)].pdf | 2020-11-10 |
| 26 | 201617033930-COMPLETE SPECIFICATION [10-11-2020(online)].pdf | 2020-11-10 |
| 27 | 201617033930-CLAIMS [10-11-2020(online)].pdf | 2020-11-10 |
| 28 | 201617033930-Power of Attorney-170321.pdf | 2021-10-17 |
| 29 | 201617033930-FER.pdf | 2021-10-17 |
| 30 | 201617033930-Correspondence-170321.pdf | 2021-10-17 |
| 31 | 201617033930-US(14)-HearingNotice-(HearingDate-28-09-2022).pdf | 2022-09-01 |
| 32 | 201617033930-REQUEST FOR ADJOURNMENT OF HEARING UNDER RULE 129A [23-09-2022(online)].pdf | 2022-09-23 |
| 33 | 201617033930-US(14)-ExtendedHearingNotice-(HearingDate-26-10-2022).pdf | 2022-09-28 |
| 34 | 201617033930-Correspondence to notify the Controller [21-10-2022(online)].pdf | 2022-10-21 |
| 35 | 201617033930-Written submissions and relevant documents [07-11-2022(online)].pdf | 2022-11-07 |
| 36 | 201617033930-PatentCertificate22-11-2022.pdf | 2022-11-22 |
| 37 | 201617033930-IntimationOfGrant22-11-2022.pdf | 2022-11-22 |
| 38 | 201617033930-RELEVANT DOCUMENTS [11-09-2023(online)].pdf | 2023-09-11 |
| 1 | googlepatents_11-02-2020.pdf |