Title of Invention

METHOD FOR AN ALL RADIO LINK PROTOCOL RLP BASED ARCHITECTURE FOR SIGNALLING AND DATA TRANSFER IN EVOLUTION DATA OPTIMIZED EVDO COMMUNICATION SYSTEMS

Abstract The present invention, in general relates to the field of mobile communication technology. The invention is related to a system and method for more efficient, flexible and relatively simple architecture for signaling and data transfer of various protocols and applications in EVDO and its evolved communication systems. An RLP provides the functionality for fragmentation/reassembly, Acknowledgement (ACK)/Negative Acknowledge (NAK), transmission and retransmission of data where RLP also does duplicate detection thereby reducing the error rate of the radio link.
Full Text FIELD OF THE INVENTION
The present invention, in general relates to the field of mobile communication technology. It describes architecture for signaling and data transfer between Access terminal and Access Network in EVDO and its evolved communication systems. The invention is related to a system and method for more efficient, flexible and relatively simple architecture for signaling and data transfer of various protocols and applications in EVDO and its evolved communication systems. More particularly, the invention relates to a system and method for an all rip based architecture for signaling and data transfer in EVDO communication systems.
DESCRIPTION OF RELATED ART
The EVDO communication system consists of several protocols and applications which define the procedures to be followed by the access network (AN) and the access terminal (AT) to communicate with each other. EVDO system defines these protocols and applications in different layers as shown in - Figure 1 (EVDO Architecture Protocols and Applications). Applications subtypes defined in the Application Layer and the Protocols like Stream Protocol (STRP), Packet Consolidation Protocol (PCP) and Medium Access Control Layer Protocols defines the procedures for signaling and data transfer between AN and AT.
The Application Layer contains different application subtypes like Signaling Application, Packet applications (Default Packet Application (DPA), Multi Flow Packet Application (MFPA), Enhanced Multi Flow Packet Application (EMFPA)) and other application subtypes. Signaling Messages and data from user applications will be transmitted and received as data packets of these application subtypes. Applications in the application layer use STRP, PCP, MAC layer and physical layer procedures for transmitting and receiving Application's data.
All Protocols and Applications use the Signaling Application to transmit and receive signaling messages. Signaling application contains Signaling Network Protocol (SNP) and Signaling Link Protocol (SLP) to carry out signaling message transfer. SNP provides message transmission services for signaling messages and SLP provides fragmentation/reassembly mechanisms, along with reliable and best-effort delivery mechanisms for signaling messages.
Packet Application subtypes like DPA, MFPA and EMFPA carry out the transfer of user application data (e.g.: data packets from IP, PPP applications) between AT and AN. Radio Link Protocol (RLP), Flow Control Protocol (FCP), and Location Update Protocol (LUP) define various procedures for transmission and reception of user data.
The Application subtypes are configured using the session configuration procedures defined in the EVDO system. Application subtypes are configured over the streams of the StreamA/irtual Stream Protocols of EVDO. By default, Signaling Application is always configured over stream 0 of STRP. Other applications may be configured onto other available streams of STRP or VSTRP through negotiation. Default Stream Protocol has only 4 streams and hence only 3 application subtypes can be configured on STRP streams other than signaling application where as Virtual stream Protocol (VSTRP) can support up to 255 application subtypes using the 255 virtual streams. After STRP/VSTRP configuration (mapping of application subtypes onto streams of STRP/VSTRP),
Application subtypes negotiates their attributes using the session negotiation procedures defined in the EVDO system. The detailed negotiation sequence for STR and the Applications are given in Figure 2.
Each application is assigned an identifier (similar to specific protocol id of EVDO protocols) based on their associated stream id (STRP) or virtual stream id (VSTRP). Signaling Application uses this identifier for routing the application's signaling messages. Signaling Message flow for Protocols and Applications is shown in Figure 3.
The Stream Layer (STRP and VSTRP) provides multiplexing and de-multiplexing for different applications. STRP and VSTRP maintain the stream- application subtype mapping and they route the data packets of each application subtype based their associated stream id. In the transmitter, STRP adds the stream id associated with each application subtype as the identifier for their respective data packet. In the receiver, STRP extracts the stream id associated with each application data packet and routes it to the respective application subtypes.
Applications mapped onto VSTRP transmit and receive their data packets as signaling messages of VSTRP. In the transmitter, VSTRP adds the virtual stream id associated with each application subtype to the data payload of the application and the data is transmitted as VSTRP's signaling message. In the receiver, VSTRP extracts the virtual stream id contained in the message and forwards the data payload of the message to the associated application subtypes. Data flow of application packets are given in Figure 4.
Packet Consolidation Protocol (PCP) consolidates the packets from various application subtypes. In the transmitter, STR protocol passes the data packet of each application along with stream header to PCP. PCP adds length of each data packet as its header information. The consolidated PCP packet is passed to the lower layers (security or Medium access Control Protocols). In the receiver, PCP receives the data packets from the lower layers and routes the application data packets to STRP along with the packet length information.
In the transmitter, MAC protocols receives various security/PCP layer packets and adds MAC header information before passing the MAC packet to physical layer. In the receiver, MAC protocols receive data from physical layer, extract the MAC header information and pass the packets to Security/PCP layer.
The Packet Application subtypes contained in the application layer can support single flow (handle a single higher layer application data) or multiple flows (handle multiple applications' data, with each flow supporting a single higher layer application). Default Packet Application provides a single flow where as MFPA and EMFPA provides multiple flows for transfer of higher layer user application data. MFPA/EMFPA provides multiple octet or packet streams that can be used to carry octets or packets between the access terminal and the access network. Each octet or packet stream is called a Link Flow. Each link flow is an RLP instance with a set of configurable attributes. The behavior of the RLP depends on the configuration of the link flow. EMFPA provides negotiation of QoS for higher layer application. Each higher layer application may have many application flows. Each application flow is allocated one or more reservations and QoS is negotiated for those reservations. Access network will grant QoS for the reservations and map them to link flows. The attributes of the link are configured to satisfy the mapped application flow (i.e., reservation) needs. The EMFPA link flows are mapped on to the MAC Flows.
Notes-
1. All Protocols are not included in the architecture.
2. Applications and protocols involved in the signaling and data transfer between AT and AN are highlighted in the above diagram
3. Security layer is not included for the signaling and data transfer description in this document.
LIMITATIONS
The following are the problems/weaknesses with the current approach -
1. In the current architecture SLP provides the functionality for fragmentation/reassembly, ACK transmission and packet retransmission for signalling messages. RLP provides the functionality for fragmentation/reassembly, ACK/NAK transmission and packet retransmission. The functionality of SLP can be handled by RLP with proper configuration of RLP and SLP can be removed.
2. In the current architecture there is a different layer PCP for consolidating all the packets. The functionality of this layer can be handled by the application layer or MAC layer with out affecting any other functionality.
3. In the current architecture there is a different layer, STRP for providing multiplexing of applications. This functionality can be handled by application layer or MAC layer without affecting any other functionality.
4. In the current architecture the packet application has all the functionality corresponding to RLP, FCP, RSP, negotiating and maintaining reservations and their QoS parameters etc. The functionality can be split so that RLP parameters and QoS parameters can be negotiated or managed independently.
5. In the current architecture TAS, DPA, MFPA, EMFPA are applications over streams. And IP, PPP, ROHC etc... are applications mapped on to the reservations. But all the applications TAS, IP, PPP, ROHC etc... can be directly mapped to streams/links.
Therefore, there is a need for defining a new architecture to efficiently handle all the above points.
SUMMARY OF THE INVENTION
The present invention generally relate^ to Evolution Data Optimized (EVDO) communication systems, and in particular to a system and method for Radio Link Protocol (RLP) based architecture for signaling and data transfer in EVDO communication systems.
An architecture for transmitting all data packets and signaling messages through RLP is described. RLP provides the functionality for fragmentation/reassembly, Acknowledgement (ACK)/Negative Acknowledge (NAK), transmission and retransmission. RLP also does duplicate detection thereby reducing the error rate of the radio link. RLP links are configurable to support the number of links negotiated for a session. Signaling Network Protocol (SNP) is used for sending and receiving signaling messages of protocols and applications. Here SNP runs over RLP and all signaling messages and data go though link flows. When SNP runs over RLP a field in the RLP header will indicate whether the payload is best effort or reliable message. Multi Link Protocol (MLP) controls multiple data streams that can be used to carry data between the access terminal (AT) and access network (AN). MLP is responsible for all link level negotiations. MLP also controls instantiation or purging of applications and mapping of applications to links. Signaling messages of the applications are handled by SNP and MLP. MLP routes the signaling message of applications to or from SNP. Data packets of the applications are multiplexed and de-multiplexed directly by Medium Access Control (MAC) and Links associated by each application.
All the applications are configured by session configuration procedure over the links of the MLP. After subtype negotiation, MLP starts its negotiation procedure by informing AN about the maximum links that can be supported by AT. On receiving the response from the AN, MLP instantiates the links and the applications mapped on to the respective links. MLP also negotiates the link flow attributes based on the application that is mapped on the link flow. In AN negotiation, AN may change the link to application mapping and configure the application parameters. MLP purges and instantiates the links and applications if AN changes the link to application mapping during AN negotiation. After negotiation, each application is identified based on their associated link. The associated link ids of the applications are used for signaling and data transfer of applications.
Accordingly the invention explains a method for an all RLP based architecture for signaling and data transfer in EVDO communication systems wherein the RLP provides the functionality for fragmentation/reassembly, Acknowledgement (ACK)/Negative Acknowledge (NAK), transmission and retransmission of data where RLP also does duplicate detection thereby reducing the error rate of the radio link.
Accordingly the invention explains a system of an all RLP based architecture for signaling and data transfer in EVDO communication systems wherein the said system provides the functionality for fragmentation/reassembly, Acknowledgement (ACK)/Negative Acknowledge (NAK), transmission and retransmission of data where RLP also does duplicate detection thereby reducing the error rate of the radio link.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1: Current EVDO Architecture (Protocols and Applications) Figure 2: Session Negotiation in the current EVDO Architecture Figure 3: Signalling Message Flow in the current EVDO Architecture Figure 4: Data Flow in the current EVDO Architecture Figure 5: Proposed architecture
Figure 6: Signalling message flow in the proposed architecture Figure 7: Data Flow in the proposed architecture Figure 8: Session Negotiation in the proposed architecture Figure 9: QoS Call setup in the proposed architecture Figure 10: QoS Call release in the proposed architecture
DETAILED DESCRIPTION OF THE INVENTION
The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. However, it should be understood that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. Therefore the details disclosed herein are not to be interpreted as limiting but merely as the basis for the claims and as a basis for teaching one skilled in the art how to make or use the invention.
The proposed architecture is an all-RLP based architecture. In this architecture all data packets and signalling messages goes through RLP. All the applications SNP, TAS, IP,
PPP, ROHC etc... are at the same level and are directly mapped on to the links. The proposed architecture is shown in Figure 5. It contains the following main blocks
1. Multi Link Protocol (MLP)
2. Resource Management Protocol (RMP)
3. Radio link protocol (RLP)
4. Signalling Network Protocol (SNP)
5. Medium access control (MAC) protocol
Multi Link Protocol (MLP) - Multi Link Protocol controls multiple data streams that can be used to carry data between the access terminal and access network. Each data stream in MLP is called a link Flow or RLP instance. MLP creates and maintains several RLP link flows. It negotiates the mapping of applications to link flows. It also negotiates the link flow attributes/parameters based on the application that is mapped on the link flow. When an application is mapped on to a link flow it instantiates the mapped application and the RLP link with configured parameters. When an application mapping is removed it purges the application.
One Link flow is reserved for SNP and one link flow is reserved for main data service instance. These reserved link flows are instantiated by default. QoS based applications are mapped on to link flows anytime during the session based on user requirements. Also MLP routes the signaling messages of mapped applications to SNP and vice versa.
Resource Management Protocol (RMP) - RMP allocates reservations and performs QoS managements for higher layer application flows. User Application like VIOP, PSVT which
require QoS requests RMP to create (map the application flow to) a bearer for transmitting and receiving application data. RMP allocates reservations and sends the QoS requirements using the signaling messages to the Access Network. Access network grants the requested QoS and maps the application flow to a Link flow and configures the link flow attributes accordingly. This mapping of application flow to a link flow happens through a signaling message of MLP.
Radio Link Protocol (RLP) -The Radio Link Protocol (RLP), which provides retransmission, and duplicate detection, thus, reduces the radio link error rate as seen by the higher layer protocols. MLP provides multiple data streams using RLP. Each RLP has a set of configurable attributes. The behavior of the RLP depends on the configured attributes. In the proposed architecture all applications run over RLP. The attributes of the RLP are configured according to the Application needs. To run SNP over RLP, new attributes ACK Rounds, ACK Timer for each round and attribute to indicate the RLP header format. When SNP runs over RLP a field in the RLP header will indicate whether the payload is best effort or reliable message. RLP would act as dummy RLP without adding header, when RLP functionalities are not required for the specific application.
Application mapping and creation - All the applications SNP, TAS, IP, PPP, ROHC etc...are configured over the links of Multi Link Protocol (MLP) using the session configuration procedures defined for the system. By default, SNP is always configured over Link 0 of MLP (RLP-0) and one link flow is reserved for main data service instance. Other applications may be configured onto other available links of MLP through negotiation. After subtype of MLP is negotiated by SCP, MLP starts its negotiation procedures. MLP informs AN about the maximum links that can be supported by AT and the applications - link mapping proposed by AT (Similar to STRP functionality in the existing architecture). On receiving the response from the AN, MLP instantiates the links and the applications mapped onto the respective links. MLP also negotiates the link flow attributes/parameters based on the application that is mapped on the link flow. After MLP configuration (mapping of application subtypes onto links MLP), Applications mapped onto the links negotiates their attributes using the session negotiation procedures defined for the system. In the AN negotiation, AN may change the link to application mapping and configure the application parameters. MLP purges and instantiates the links and applications if AN changes the link to application mapping during AN negotiation (Similar to STRP functionality in the existing architecture).
After negotiation, each application is identified based on their associated link. The associated link ids of the applications are used for signaling and data transfer of applications. The detailed negotiation sequence for MLP, Link attributes and the Applications are given in Figure 8.
Signalling Application over RLP - Signalling Network Protocol is used for sending and receiving signalling messages (both best effort and reliable) of protocols and applications. In this architecture SNP runs over RLP. RLP provides the retransmission and fragmentation functionalities for signalling messages. Separate protocol, SLP for performing reliable delivery and fragmentation procedures, is not required. Some of the methods to make SNP over RLP are described below.
Proposal 1
An attribute of the RLP will be used to configure the ACK rounds and Ack timer. Ack rounds and Ack timer are uses for reliable delivery. A separate RLP flow will be used for best effort and reliable delivery. SNP uses one RLP flow for best effort and one RLP flow for reliable delivery. NAK and ACK disabled for the RLP flow carrying best effort delivery. Configure ACK rounds and ACK timer for transmitter side and enable ACK on the receiver side for Reliable delivery RLP flow.
Proposal 2
One more approach is to have a field in the RLP header to indicate reliable delivery or beset effort delivery and configure SNP on one RLP Flow. Transmitter will set the field according to the payload RLP packet is carrying. ACK timer is started for the RLP packets carrying reliable payload. Up on expiry of ACK timer, transmitter will retransmit the RLP packet and start the ACK timer. Transmitter will retransmit for ACK rounds number of times if ACK is not received. On the receiver side, ACK will be sent for the RLP packets carrying reliable delivery. If the received fragment makes a complete packet, then pass the packet to the SNP. When some RLP packets are missed, they might indicate best effort or reliable or both. If the received fragment indicates few fragments are lost, wait till abort timer interval. (Abort timer would be set based on the transmitter ACK timer and ACK rounds). Abort timer need not be started if all missed fragments indicate best effort, If some fragments of a best effort packet are missed, discard all the received fragments of that best effort RLP packet, till first segment of another best effort packet is received.
Signalling Flow of protocols and applications
All Signaling Messages of AT shall be transmitted and received through SNP. Signaling messages will be transmitted and received as data packets of RLP-0 instance (mapped to SNP). SNP transmits and receives signaling messages of the protocols using the protocol ID of the protocol. All application mapped on to the RLP link flows use SNP for transmitting and receiving signaling messages. Signaling messages of applications shall be routed to/from SNP based on the protocol id (OxPPXX), where XX indicates link id and
PP identifies that this message is for an application. MLP/SNP shall route the message to the application mapped on link XX. Signaling flow for application is shown in Figure 6.
Application Data Flow
Data packets of the applications are multiplexed and demultiplexed directly by MAC and Links associated with each Application. In the transmit direction MAC does consolidation of data from various applications. RLP would act as dummy RLP without adding header, when RLP functionalities are not required for the specific application. On the receive direction MAC does de-multiplexing based on the RLP ID. User Applications which require QoS requests RMP for setup of a channel for sending and receiving data. RMP allocates reservations and sends the QoS requirements using the signaling messages to the Access Network. Access network grants the requested QoS and maps the application flow to a Link flow and configures the link flow attributes accordingly. This mapping of application flow to a link flow happens through a signaling message of MLP. All the user - application data will be transmitted/received using the mapped link flow. Data flow for applications is shown in Figure 7. QoS call setup procedure is shown in Figure 9 and QoS call release procedure is shown in Figure 10.
Alternative to the Proposed Architecture
1. PCP layer can be added between MAC and Link layers in case same security is to be applied for all the links. In this case, PCP shall consolidate the data packet from the links and security can be applied to the whole consolidated packet by security layer. Security layer shall forward the security applied packet to MAC layer in the transmit side and in the receiving side, Security layer shall receive the data packet from MAC, remove the security header information and forward the packet to PCP.
ADVANTAGES
The proposed architecture has the following features/advantages compared with the current architecture
1. All the applications SNP, TAS, IP, PPP, ROHC etc... are at the same level and are directly mapped on to links. Hence there is no need for separate applications like DPA, MFPA etc... to handle higher layer applications
2. RLP link flow handles both signalling messages and data packets delivery. Hence there is no need for a separate protocol (SLP) for handling signalling message delivery.
3. The negotiation of link level parameters and QoS parameters is separated and is handled by MLP and RMP respectively. Hence these parameters can be negotiated independently.
4. The negotiation and maintenance of reservations and their QoS parameters are handled by a separate entity Resource Management Protocol (RMP).
5. The functionality of stream and PCP layers are handled at MAC layer hence these two layers are not required. This reduces the number of layers in data/signaling flow.
6. The maximum number of links that AT/AN supports is configurable.
7. One single RLP flow handles the functionality for both best effort and reliable message delivery. (Proposal -2)
Although, the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart there from.
GLOSSARY OF TERMS AND DEFINITIONS THEREOF
Access Network: The network equipment which provides data connectivity between a packet switched data network (typically the Internet) and the access terminals
Access Terminal: A device providing data connectivity to a user. An access terminal may be connected to a computing device such as a laptop personal computer or it may be a self-contained data device such as a personal digital assistant. An access terminal is equivalent to a mobile station.
EV-DO: CDMA2000 1x evolution-Data Optimized system.


We Claim,
1. A method for an all RLP based architecture for signaling and data transfer in EVDO communication systems wherein the RLP provides the functionality for fragmentation/reassembly, Acknowledgement (ACK)/Negative Acknowledge (NAK), transmission and retransmission of data where RLP also does duplicate detection thereby reducing the error rate of the radio link.
2. A method as claimed in claim 1 wherein the RLP links are configurable to support the number of links negotiated for a session.
3. A method as claimed in claim 1 further comprises the steps of sending and receiving signaling messages of protocols and applications using a Signaling Network Protocol (SNP) where the SNP runs over RLP and all signaling messages and data go though link flows.
4. A method as claimed in claim 3 wherein when SNP runs over RLP a field in the RLP header will indicate whether the payioad is best effort or reliable message.
5. A method as claimed in claim 1 wherein a Multi Link Protocol (MLP) controls multiple data streams that is used to carry data between the access terminal (AT) and access network (AN) where the MLP is responsible for all link level negotiations.
6. A method as claimed in claim 1 wherein the MLP also controls instantiation or purging of applications and mapping of applications to links where the Signaling messages of the applications are handled by SNP and MLP.
7. A method as claimed in claim 5 wherein the MLP routes the signaling message of applications to or from SNP.
8. A method as claimed in claim 1 wherein Data packets of the applications are multiplexed and de-multiplexed directly by Medium Access Control (MAC) and Links associated by each application where the applications are configured by session configuration procedure over the links of the MLP.
9. A method as claimed in claim 1 wherein after subtype negotiation, MLP starts its negotiation procedure by informing AN about the maximum links that can be supported by AT and on receiving the response from the AN, MLP instantiates the links and the applications mapped on to the respective links.
10. A method as claimed in claim 9 wherein MLP also negotiates the link flow attributes based on the application that is mapped on the link flow.
11. A method as claimed in claim 10 wherein in AN negotiation, AN changes the link to application mapping and configure the application parameters.
12. A method as claimed in claim 11 wherein MLP purges and instantiates the links and applications if AN changes the link to application mapping during AN negotiation.
13. A method as claimed in claim 12 wherein after negotiation, each application is identified based on their associated link where the associated link ids of the applications
are used for signaling and data transfer of applications.
14. A system of an all RLP based architecture for signaling and data transfer in EVDO communication systems wherein the said system provides the functionality for fragmentation/reassembly, Acknowledgement (ACK)/Negative Acknowledge (NAK), transmission and retransmission of data where RLP also does duplicate detection thereby reducing the error rate of the radio link.
15. A method for an all RLP based architecture for signaling and data transfer in EVDO communication systems substantially described particularly with reference to the accompanying drawings.
16. A system of an all RLP based architecture for signaling and data transfer in EVDO communication systems substantially described particularly with reference to the accompanying drawings.

Documents:

1349-CHE-2006 AMENDED PAGES OF SPECIFICATION 10-12-2013.pdf

1349-CHE-2006 AMENDED CLAIMS 10-12-2013.pdf

1349-CHE-2006 CORRESPONDENCE OTHERS 15-04-2014.pdf

1349-CHE-2006 FORM-1 10-12-2013.pdf

1349-CHE-2006 FORM-13 17-12-2013.pdf

1349-CHE-2006 OTHER PATENT DOCUMENT 10-12-2013.pdf

1349-CHE-2006 POWER OF ATTORNEY 10-12-2013.pdf

1349-CHE-2006 EXAMINATION REPORT REPLY RECEIVED 10-12-2013.pdf

1349-CHE-2006 FORM-13 13-12-2013.pdf

1349-CHE-2006 ABSTRACT.pdf

1349-CHE-2006 CLAIMS.pdf

1349-CHE-2006 CORRESPONDENCE OTHERS.pdf

1349-CHE-2006 CORRESPONDENCE PO.pdf

1349-CHE-2006 DESCRIPTION (COMPLETE).pdf

1349-CHE-2006 DRAWINGS.pdf

1349-CHE-2006 FORM 18.pdf

1349-CHE-2006 FORM 5.pdf

1349-che-2006-correspondnece-others.pdf

1349-che-2006-description(provisional).pdf

1349-che-2006-drawings.pdf

1349-che-2006-form 1.pdf

1349-che-2006-form 26.pdf

1349-CHE-2008 AMENDED PAGES OF SPECIFICATION 23-05-2014.pdf

1349-CHE-2008 AMENDED CLAIMS 23-05-2014.pdf

1349-CHE-2008 EXAMINATION REPORT REPLY RECEIVED 23-05-2014.pdf

1349-CHE-2008 FORM-1 23-05-2014.pdf

1349-CHE-2008 POWER OFATTORNEY 23-05-2014.pdf


Patent Number 261142
Indian Patent Application Number 1349/CHE/2006
PG Journal Number 24/2014
Publication Date 13-Jun-2014
Grant Date 06-Jun-2014
Date of Filing 31-Jul-2006
Name of Patentee SAMSUNG R& D INSTITUTE INDIA BANGALORE PRIVATE LIMITED
Applicant Address #2870 ORION BUILDING BAGMANE CONSTELLATION BUSINESS PARK OUTER RING ROAD DODDANEKUNDI CIRCLE MARATHAHALLI POST BANGALORE -560037
Inventors:
# Inventor's Name Inventor's Address
1 VADLAPUDI TIRUMALA SREE HARI VARA PRASAD Employed at Samsung India Software Operations Pvt. Ltd., having its office at, Bagmane Lakeview, Block 'B', No. 66/1, Bagmane Tech Park, C V Raman Nagar, Byrasandra, Bangalore - 560093, KARNATAKA, INDIA
2 GODAVARTI SATYA VENKATA UMA KISHORE Employed at Samsung India Software Operations Pvt. Ltd., having its office at, Bagmane Lakeview, Block 'B', No. 66/1, Bagmane Tech Park, C V Raman Nagar, Byrasandra, Bangalore - 560093,
3 RAVI KUMAR G Employed at Samsung India Software Operations Pvt. Ltd., having its office at, Bagmane Lakeview, Block 'B', No. 66/1, Bagmane Tech Park, C V Raman Nagar, Byrasandra, Bangalore - 560093,
4 SONA K RAJ Employed at Samsung India Software Operations Pvt. Ltd., having its office at, Bagmane Lakeview, Block 'B', No. 66/1, Bagmane Tech Park, C V Raman Nagar, Byrasandra, Bangalore - 560093,
PCT International Classification Number H04M03/00
PCT International Application Number N/A
PCT International Filing date
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 NA