Title of Invention

METHOD SYSTEM AND AGENT FOR 3 GPP TECHNICAL SPECIFICATION DOCUMENT NUMBER EXCHANGE

Abstract N/A
Full Text FORM 2
THE PATENTS ACT 1970 [39 OF 1970]
&
THE PATENTS RULES, 2003 COMPLETE SPECIFICATION
[See Section 10; rule 13]
"METHOD SYSTEM AND AGENT FOR 3GPP TECHNICAL SPECIFICATION DOCUMENT NUMBER EXCHANGE"
TELEFONAKTIEBOLAGET LM ERICSSON (PUBL), S-126 25 Stockholm, Sweden,
The following specification particularly describes the invention and the manner in which it is to be performed:

WO 02/098096

PCT/CA02/00723

Method, System and Agent for 3GPP Technical Specification Document Number
Exchange
5 PRIORITY UNDER 35 U.S.C. S 119(e) & 37 CFR S 1.78
This nonprovisional patent application claims priority based upon the prior U.S provisional patent application entitled "Method of IRP Versioning", application number 60/293,802, filed on 05/25/2001, in the names of Andre Godin, Nicolas Gosselin, David McAleer and Edwin Tse.
10
BACKGROUND OF THE INVENTION
Field of the Invention
The present invention relates generally to the field of communications networks
15 and, more specifically, to standard identification communications between telecommunications nodes.
Description of the Related Art
A communications network typically comprises a plurality of communications
20 nodes, which "speak" to each other by exchanging various classes of messages, representing commands, data, requests, replies, notifications or others, according to the technology and protocol used within each such network. For meaningful communications to take place between communications nodes, the message syntax and semantics must be understood and agreed among the communicating nodes. The
2 5 document that specifies the syntax and semantics of the messages exchanged between
nodes is sometimes called the interface specification, technical specification or protocol. At the operation level, the Integration Reference Point (IRP) is one of such protocols, through which the communications messages are exchanged between nodes in a management system. There are many types of IRP specifications or protocols, such as
30 for example for fault management (Alarm IRP) and for configuration management
(Basic Configuration IRP).
l
SUBSTITUTE SHEET (RULE 26)

WO 02/098096

PCT/CA02/00723

In 3rd Generation Partnership Project (3GPP) based communications
environments, the IRP specifications define and control network management-related
communications between an Element Management - Network Management node (EM-
NM) and the controlled Network Elements nodes (NEs).
5 Various IRP specifications exist for defining communications in a plurality of
network management sub-fields. In the fault/alarm management field, one of the most basic needs is to support alarm surveillance. Product specific applications use the Alarm IRP specification to be able to forward alarm notifications from various NEs and to a Fault Monitoring (FM) application. Another IRP specification is the Basic
10 Configuration Management IRP specification that defines and controls the management of topology and logical resources in the managed network (retrieval of the configuration and status of the network elements). Finally, the Performance Monitoring (PM) is achieved according to the Performance Data IRP specification.
Reference is now made to Fig. 1.a (Prior Art), which shows a nodal operation
15 and signal flow diagram of a typical prior art scenario for exchanging IRP specification
names between two communications nodes. In Fig. l.a, a management system 100
comprises an IRP Manager 102 that communicates with an IRP Agent 104. For this
purpose, the Manager 102 must first know the supported IRP specification and version
used and supported by the IRP Agent 104. Each type of IRP specification defines a
20 mandatory method called getXXXIRPVersionO, wherein "XXX" refers to the given
type of IRP specification. For example, the method getAlarmIRPVersion() is used for
deducting the Alarm IRP specification supported by a given node. With reference to
Fig. l.a (Prior Art), prior to any further communications, the IRP Manager 102
transmits a getXXXIRPVersion request message 106 to Agent 104 for inquiring of the
25 Agent's supported IRP specification version, to which the Agent 104 replies with a
getXXXIRPVersion reply message 108 comprising a parameter 110 indicative of a list
of elements, each containing the name and the version number the Agent's supported
IRP specifications. In current implementation, an element of the parameter 110 consists
of three characters, such as for example "1 fl".
3 0 Reference is now made to Fig. l.b (Prior Art), which shown a schematic
representation of the structure of one element 120 of the parameter 110 returned in the
message 108 shown in Fig. l.a. The element 120 consists of three segments 122, 124
2
SUBSTITUTE SHEET (RULE 26)

WO 02/098096

PCT/CA02/00723

and 126, wherein the first segment 122 refers to the IRP IS version number (which represent the version number of the IRP Information Service), the second segment 124 refers to the type of IRP specification type, and the third segment refers to the IRP SS version number (which represent the version number of the IRP Solution Set). For example, the string "lfl" means that the Agent 104 (shown in Fig. l.a) implements the IRP IS version number 1 of the ("f', Fault) Alarm IRP specification, IRP SS version number 1.
There are three problems with the above way of handling and transmitting the
IRP specification name and version. The first problem is that the IRP specifications
evolve through the acceptance by the standard body of multiple technical specification
Change Requests (CRs) made by industry players. CRs writers do not always take into account if their proposed changes affect the IRP version number or not. CR writers
typically do not suggest to change the constant strings representing the notification categories in the NotificationlRPConstDefs IDL file, an Interface Description Language (IDL). Referring to Fig 1 .a, the notification categories are represented by the parameter 110 comprised in message 108. If the constant strings representing the notification categories are not adequately changed in the NotificationlRPConstDefs IDL file (not shown in Fig. l.a; information from the IDL file defines the IRP type and version number, and is compiled by the Agent for the generation of the appropriate parameter
110) as and when required by CRs, which oftentimes occurs nowadays, IRP Manager 102 may be given the erroneous IRP version supported by the Agent 104.
The second problem is the lack of clear understanding of the standard body members on how to handle multiple CRs, where some CRs affect backward compatibility while others do not. By not considering that some CRs affect backward
compatibility or by processing CRs in the wrong order, the process may end-up by having wrong values for constant strings representing the notification categories, such as the values sent in parameter 110 of Fig. l.a.
Finally, the third problem is that whenever a version number of any IRP specification is changed, it also requires a new version number for the given
Notification IRP specification, since all the constant strings representing the notification categories are defined in a NotificationlRPConstDefs IDL file, which is included in a Notification IRP SS document. Consistent reviews of all IRP specifications impacted by
3
SUBSTITUTE SHEET (RULE 26)

WO 02/098096

PCT/CA02/00723

an accepted CR are not always performed by the standard body, which sometimes
creates transmission confusion and errors between interconnected nodes implementing
signalling based upon the given IRP specification.
Accordingly, it should be readily appreciated that in order to overcome the
5 deficiencies and shortcomings of the existing solutions, it would be advantageous to have a scheme that unequivocally identifies a technical specification (protocol) used by co-operating nodes. The present invention provides such a solution.
10 SUMMARY OF THE INVENTION
In one aspect, the present invention is a method for transmitting an indication of a communications protocol supported by a first communications node, the method comprising the steps of:
i) transmitting from a second communications node to the first communications
15 node a request for a protocol supported by the first communications node; and
ii) responsive to the request, transmitting a reply message comprising a
parameter indicative of a Third Generation Partnership Project (3GPP) Technical
Specification (TS) document number defining at least a protocol supported by the first
communications node.
20 In another aspect, the present invention is a management system comprising:
a second node;
a first node receiving from the second communications node a request for a protocol supported by the first communications node;
wherein responsive to the request, the first node transmits to the second node a
25 reply message comprising a parameter indicative of a Third Generation Partnership Project (3GPP) Technical Specification (TS) document number defining at least a protocol supported by the first communications node.
In yet another aspect, the present invention is an agent receiving from a manager
a request for a protocol supported by the Agent, and responsive to the request,
30 transmitting a reply message comprising a parameter indicative of a Third Generation
Partnership Project (3GPP) Technical Specification (TS) document number defining at
least a protocol supported by the agent.
4
SUBSTITUTE SHEET (RULE 26)

WO 02/098096

PCT/CA02/00723

Brief Description of the Drawings
For a more detailed understanding of the invention, for further objects and
advantages thereof, reference can now be made to the following description, taken in
conjunction with the accompanying drawings, in which:
5 Figure 1 .a (Prior Art) is a nodal operation and signal flow diagram of a typical
prior art scenario for exchanging Integration Reference Point (IRP) specification names and versions between two communications nodes;
Figure l.b (Prior Art) is a schematic representation of the structure of an element
of the getXXXIRPVersion reply message used in a typical prior art scenario for
10 exchanging IRP specification names and versions between two communications nodes;
Figure 2.a is a nodal operation and signal flow diagram illustrative of the
Partnership Project (3GPP) document number in communications between cooperating
nodes in a network management system; and
15 Figure 2.b is an exemplary flowchart diagram illustrative of the set-up of an
exemplary abridged technical specification version number computed according to the preferred embodiment of the present invention.
Detailed Description of the Preferred Embodiments
20 The innovative teachings of the present invention will be described' with
particular reference to numerous exemplary embodiments. However, it should be understood that this class of embodiments provides only a few examples of the many advantageous uses of the innovative teachings of the invention. In general, statements made in the specification of the present application do not necessarily limit any of the
25 various claimed aspects of the present invention. Moreover, some statements may apply to some inventive features but not to others. In the drawings, like or similar elements are designated with identical reference numerals throughout the several views, and the various elements depicted are not necessarily drawn to scale.
The Third Generation Partnership Project (3GPP) assigns document numbers,
30 such as for example the document number "3GPP TS 32.106-3 v3.2.0" to each 3GPP
technical specification it publishes. IDL files and GDMO (General Definition of Managed Objects) definitions, which represent the protocol interface and the managed
5
SUBSTITUTE SHEET (RULE 26)

WO 02/098096

PCT/CA02/00723

object model to support, are part of the 3GPP technical specification having a unique document number. Therefore, the present invention proposes to use the 3 GPP document number of each 3 GPP technical specification in order to unambiguously identify the IDL files and GDMO definitions used by each node in communications between
5 cooperating nodes of a communications network.
Referring now to Fig. 2.a, depicted therein is a nodal operation and signal flow diagram illustrative of the preferred embodiment of the present invention related to the use of the 3 GPP document number in communications between cooperating nodes in a network management system. The network management system 200 comprises an
10 Agent 202 in communication with a Manager 204. Prior to exchanging any message, the Manager 204 must know the protocol used and supported by the Agent 202. For example, the Manager 204 may inquire of the supported technical specification (protocol) used by the cooperating Agent 202 (the IDL definition it supports) by sending a GetXXXIRPVersion request message 210 to the Agent 202. Upon receipt of
15 the request message 210, according to the preferred embodiment of the invention, the Agent computes (including retrieving from a memory) an abridged technical specification version number that uniquely identifies the used protocol, action 212, and returns the abridged technical specification version number 214 to the Manager 204 in a GetXXXIRPVersion reply message 216. If the Agent 202 supports multiple versions of
20 the alarm IRP:SS (the Alarm IRP Solution Set), then the Agent includes in the reply message 216 a plurality of abridged version numbers, each of which identifies a specific version of 3GPP Alarm IRP:SS technical specification. In this manner, the Manager 204 is informed of all the Alarm IRP:SS technical specifications supported by the Agent 202. Based on this first exchange, Manager 204 knows exactly which protocol to use to
25 send requests to Agent 202.
Reference is now made to Fig. 2.b, which shows an exemplary flowchart diagram illustrative of a set-up of an exemplary abridged technical specification version number that may be computed in step 212 of Fig. 2.a. According to the invention, the method starts at 300 with the full name of a 3 GPP technical specification, such as for
30 example with "3GPP TS 32.106-3 v3.2.0" 302. At step 304, the method discard the header of the technical specification name, and the name is reduced to the string "32.106-3 v3.2.0" 306. At step 308, the method discards all characters after (and
6
SUBSTITUTE SHEET (RULE 26)

WO 02/098096

PCT/CA02/00723

including) the last period, and the string name is further reduced to "32.106-3 v3.2" 310. Finally, at step 312, the method eliminates all white spaces from the remaining string and capitalizes the final string, that becomes the computed abridged technical specification version number "32.106-3V3.2" 214.
Reference is now made back to Fig. 2.a, which further shows another use of the abridged technical specification version number according to the preferred embodiment of the invention. The Manager 204 transmits a GetNotificationCategory request message 220 for inquiring of the technical specification version of the alarm notifications sent by the Agent 202. The Agent 202 receives the request 220, and
computes the abridged technical specification version number in the manner already described with relation to Fig. 2.b. Then the Agent 202 returns the abridged technical specification version number 214 to the Manager 204 in a GetNotificationCategory reply message 222. Following message 222, all the alarm notifications 224 and 226 sent by the Agent 202 to Manager 204 comprise the abridged technical specification version
number 214 in their header so that Manager 204 knows exactly the format of the notification it receives from Agent 202.
Fig. 2.a further shows yet another use of the abridged technical specification
version number according to the preferred embodiment of the invention. The Manager
204 may transmit a GetNetworkResourceSchemalD request message 240 for inquiring
of the set of Managed Object Classes (e.g. Generic NRM, UTRAN NRM) of the
network resource schema identification. The set of Managed Object Classes of the
network resource schema identification defines all the Managed Object classes and their
attributes. The Agent 202 computes the technical specification version number of the
supported technical specification, as previously described with relation to Fig. 2.a. For
example, if the Agent 202 supports one particular version of the Generic NRM and one
particular version of the UTRAN (UMTS Terrestrial Radio Access Network) NRM, the
getNetworkResourceSchemaldO reply message 242 to the
getNetworkResourceSchemaId() request message 240 may contain two abridged version numbers 214) and 2142, each of which identifies a specific 3GPP specification.
If the Agent 202 supports two particular versions, one of which is backward compatible to the other, of the Generic NRM, the getNetworkResourceSchemaldO reply message
7
SUBSTITUTE SHEET (RULE 26)

WO 02/098096

PCT/CA02/00723

242 also contains two abridged version numbers, each of which identifies a specific supported version of the 3GPP specification.
Based upon the foregoing, it should now be apparent to those of ordinary skill in the art that the present invention provides an advantageous solution, which offers
unambiguous identification of the appropriate technical specification (protocol) used by cooperating nodes. Therefore, the invention simplifies the handling of the standard change request process, eliminates the need to update constant strings in IDL file(s), and allows for unambiguous identification of the protocol used by cooperating nodes. It should be realized upon reference hereto that the innovative teachings contained herein
are not necessarily limited to the disclosed examples. For example, although the invention has been described with reference to communications between an agent and a manager of a management system, it is understood that the invention is also applicable to any kind of networks and network nodes. It is believed that the operation and construction of the present invention will be apparent from the foregoing description.
While the method and system shown and described have been characterized as being preferred, it will be readily apparent that various changes and modifications could be made therein without departing from the scope of the invention as defined by the claims set forth hereinbelow.
Although several preferred embodiments of the method and system of the
present invention have been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it will be understood that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.







8
SUBSTITUTE SHEET (RULE 26)

We CLAIM :-
1 A method for transmitting- an indication of a. communications protocol supported by
a first communications node, the method comprising' the steps of:
i) transmitting from a second communications node to the first communications
node a request for a protocol supported by the first communications node;'
ii) issuing a parameter indicative of .the protocol supported by the first
communications node by abridging a Third Generation Partnership Project (3GPP) i
Technical Specification (TS) document number defining at least a protocol supported by the "first communications node;
iii) responsive to the request, transmitting a reply message from the first communication node to the second communications node, the reply message comprising the parameter indicative of .the 3 GPP TS document number defining the at least one protocol supported by the first communications node.
2. The method as claimed in claim 1,. wherein step ii) comprises the step of:
discarding a header of the 3GPP TS document number;
discarding all characters following and including a last period of the 3GPP TS
document number; and
discarding all spaces of the 3GPP TS document number and capitalizing the 3GPP TS
document number.
3. The method as claimed in claim 1, wherein the first communications node is system
management agent, and the second communications node is a system management manager of a
management system.
4-. The method as claimed in claim 1, wherein the request for a protocol supported by the
first communications node is a getXXXtRPVersion request message and the reply message is
a getXXXIPvPVersion reply message comprising the parameter indicative of at least one





-9-
3GPP TS document number identifying at least one XXX IRP Version supported by the ' first communications node.
5. The method as claimed in claim 4, wherein the getXXXIRPVersion request message is
a getAiarmIRPVersion request and the getXXXIRPVersion reply message is a. getAilarmIRPVersion reply message comprising the parameter indicative of the at least pne ' 3GPP TS document number identifying at least one Alarm IRP Version, supported by the first communications node.
6. The method as claimed in claim 1, wherein the request for a protocol supponeu by the
first' communications node is a getNotificationCategory request message-and the reply message is a getNotificationCategory reply message comprising the parameter indicative of at least one 3GPP TS document number identifying at least one notification, category supported by the first communications node.
7. The method as claimed in claim 6, wherein the method further comprises the step of:
following the receipt of the getNotificationCategory reply message by the second communications node, transmitting from the first communications node to the second communications node at least one Alarm Notification message comprising the parameter indicative of the 3GFP TS document number,
8. The method as claimed in claim 1, wherein the request for a protocol supported by the
first :communications node is a getNetworkResourceSchemald request message and the reply message is a getNetworkResourceSchernald reply message comprising the parameter indicative of at least one 3GPP TS document number identifying at least one network resource schema identification (ID) supported by the first communications node.
9. The method as claimed in claim 1, wherein the parameter is indicative of a plurality of
3GPF TS document numbers identifying a plurality of protocols supported by the first communications node.







-10-
10. A management system comprising:
a second node;
a first node receiving from the second communications none a request, for a process
supported by the first communications node;
wherein the first communications node issues a parameter indicative of one or more protocols it supports by abridging at least one Third Generation. Partnership Project (3GPP)' Technical Specification {TS) document number defining at -least a protocol supported by the .first communications node and, responsive to the request, transmits to the second' communications node a reply, message comprising the computed parameter indicative of the SQPP TS document number defining the at least one protocol supported by the first communications node.
11 The management system as claimed in claim 10, wherein the first node computes the
abridged 3 GPP TS document version number by:
discarding a header of the 3GPP TS document number;
discarding all characters following and including a last period of the 3GPP TS-document
number,- and
discarding all spaces of the 3GPP TS document number and capitalizing the 3GPP TS
document number.
12. The management system as claimed in claim 10, wherein are use communications node is a system management agent, and the second communications node is a system management manager of a management system.
13. The management system as claimed in claim 10, wherein the request for a protocol supported by the .first communications node is a getXXXIRPVersion request message and
the reply message is a getXXXIRPVersion .reply message comprising-the parameter indicative of at least one 3GPP TS document number identifying at least one XXX ERP Version supported by the first communications node.
-11-
14. The management system as claimed in claim 13, wherein die getXXXIRPVersion
request message is a getAlarmIRPVersion request and the getXXXIRPVersion reply: message is a getAlarmIRPVersion reply message comprising the parameter indicative of the at least one 3GPP TS document numbers, identifying at least one Alarm IRP Version supported by the first communications node.
15. The management system as claimed in claim 10, wherein the request for a protocol
supported by the first communications node is a gertNotificationCategory request message and ;the
reply message is- s. getNotificationCategory reply message comprising the
parameter indicative of at least one 3GPP TS document number identifying at least one:
notification category supported by the first communications node.

16. .The management system as claimed in claim 15, wherein following the receipt of the
getNotificationCategory reply message by the second communications node, the first communications
node transmits to the second communications node at least One Alarm Notification message comprising me parameter indicative of the 3 GPP TS document number.
17. The management system as claimed in claim 10, wherein the request for a protocol
supported by the first communications node is a getNerworkRecsourceSchemald request
message and the reply message is a getNetworkResourceSchemald reply message;
comprising the parameter indicative of at least one 3GPP TS document number identifying
at least one network resource' schema identification (ID) supported by the first,'
communications node
18. The management system as claimed in claim 10, wherein the parameter is indicative of
a plurality of 3 GPP TS document numbers identifying a plurality of protocols supported by
the first communications node.














-12-

19- An agent receiving from a manager a request for a protocol supported by the Agent,
the agent issuing a parameter indicative of one or more protocols it supports by abridging at • least' one Third Generation Partnership Project (3GPP) Technical Specification (TS) document number defining at least a protocol supported by the first communications node and, irresponsive to the request, transmits-to the second communications node a reply message comprising the computed parameter indicative Of the 3GPP TS document number defining the at lease one protocol supported by agent
20. The agent as claimed in claim 22, wherein the agent computes the abridged the 3GPP
TS document Dumber by;
discarding a header of the 3GPP TS document number;
discarding all characters following and including a last period of the 3GPP TS document number; and
discarding all spaces of the 3GPP TS document number and capitalizing the 3GPP TS document number.
21 The agent as claimed in claim 19, wherein the request for a protocol supported by the
agent is a getXXXIRPVerson request message and the reply message .is a getXXIRPVersion reply message comprising the parameter indicative of at least one 3 GPP TS document number identifying at least one XXX IRP Versions supported by the
agent
22. The agent as claimed in claim 21, wherein the getXXXIRPVersion request message is
a getAlarmIRPVersion request and the getXXXTRPVersion reply message is a
getAarmIRPVersion reply message comprising the parameter indicative of the at least
one 3 GPP TS document number identifying at least one Alarm IRP Version supported by
the agent.
-13-

23. The agent as claimed in claim 19, wherein the request for a protocol supported by the
agent is a gerNotificationCategory request' message and the reply message is a getNotification Category reply message comprising the. parameter indicative of at least one: 3 GPP TS document number identifying at least one notification category supported by the agent
24. The agent as claimed in claim 23, wherein following the receipt of the
gerNottificationCategory reply message by the Manager, the agent transmits to the Manager at least one Alarm Notification message comprising the parameter indicative of the 3GPP
TS 'document number.
25. The agent as claimed in claim 19, wherein the request for a protocol supported by the
agent is. a getNetworkResourceSchemald request message and the reply message is a getNetworkResourceSchemald reply message comprising the- parameter indicative of at least! one 3GPP TS document number Identifying at-least one network .resource schema identification (ID) supported by the agent
26. The agent as claimed in claim 19, wherein the parameter-is indicative of a plurality of
3GPP TS document numbers identifying a plurality of protocols supported by the agent.
Dated this 23rd day of July 2005.

-14-

Documents:

823-mumnp-2005-abstract(complete)-(25-7-2005).pdf

823-mumnp-2005-abstract(granted)-(19-6-2009).pdf

823-MUMNP-2005-ANNEXURE TO FORM 3(28-12-2007).pdf

823-mumnp-2005-cancelled pages(5-5-2008).pdf

823-mumnp-2005-claims(amended)-(5-5-2008).pdf

823-mumnp-2005-claims(complete)-(25-7-2005).pdf

823-mumnp-2005-claims(granted)-(19-6-2009).pdf

823-mumnp-2005-claims.doc

823-mumnp-2005-claims.pdf

823-mumnp-2005-correspondence 1(30-3-2007).pdf

823-MUMNP-2005-CORRESPONDENCE(1-12-2008).pdf

823-MUMNP-2005-CORRESPONDENCE(25-5-2009).pdf

823-mumnp-2005-correspondence(5-5-2008).pdf

823-mumnp-2005-correspondence(ipo)-(2-7-2009).pdf

823-mumnp-2005-correspondence-received-ver-110106.pdf

823-mumnp-2005-correspondence-received-ver-130106.pdf

823-mumnp-2005-correspondence-received.pdf

823-mumnp-2005-description (complete).pdf

823-mumnp-2005-description(granted)-(19-6-2009).pdf

823-mumnp-2005-drawing(28-12-2007).pdf

823-mumnp-2005-drawing(granted)-(19-6-2009).pdf

823-mumnp-2005-drawings.pdf

823-MUMNP-2005-FORM 1(28-12-2007).pdf

823-mumnp-2005-form 13(3-5-2006).pdf

823-mumnp-2005-form 2(granted)-(19-6-2009).pdf

823-mumnp-2005-form 2(title page)-(complete)-(25-7-2005).pdf

823-mumnp-2005-form 2(title page)-(granted)-(19-6-2009).pdf

823-mumnp-2005-form 3(28-12-2007).pdf

823-mumnp-2005-form-1.pdf

823-mumnp-2005-form-18.pdf

823-mumnp-2005-form-2.doc

823-mumnp-2005-form-2.pdf

823-mumnp-2005-form-26.pdf

823-mumnp-2005-form-3.pdf

823-mumnp-2005-form-5.pdf

823-mumnp-2005-form-pct-ib-304.pdf

823-mumnp-2005-form-pct-isa-220.pdf

823-mumnp-2005-pct-search report.pdf

823-mumnp-2005-power of authority(3-5-2006).pdf

823-mumnp-2005-specification(amended)-(28-12-2007).pdf

823-mumnp-2005-wo international publication report(25-7-2005).pdf

abstract-1.jpg


Patent Number 234911
Indian Patent Application Number 823/MUMNP/2005
PG Journal Number 28/2009
Publication Date 10-Jul-2009
Grant Date 19-Jun-2009
Date of Filing 25-Jul-2005
Name of Patentee TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
Applicant Address S-126 25 STOCKHOLM, SWEDEN.
Inventors:
# Inventor's Name Inventor's Address
1 DAVID MCALEER 306 LONDON DRIVE, BEACONSFIELD, QUEBEC H9W 5X5, CANADA.
2 EDWIN TSE 4976 JEAN BRILLANT, MONTREAL, QUEBEC H3W 1T7, CANADA.
3 ANDRE GODIN 726 OVIDE , LAVAL, QUEBEC H7R 5X2, CANADA;
4 NOCOLAS GOSSELIN 110 DE BLAINVILLIER, BLAINVILLE, QUEBEC J7C 4 Y1, CANADA.
PCT International Classification Number H04L12/24,29/06
PCT International Application Number PCT/CA02/00723
PCT International Filing date 2002-05-22
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 10/024,234 2001-12-21 U.S.A.
2 60/293,802 2001-05-25 U.S.A.