CN101415013A - Method for identifying endpoint designation data packet - Google Patents
Method for identifying endpoint designation data packet Download PDFInfo
- Publication number
- CN101415013A CN101415013A CNA2008102275554A CN200810227555A CN101415013A CN 101415013 A CN101415013 A CN 101415013A CN A2008102275554 A CNA2008102275554 A CN A2008102275554A CN 200810227555 A CN200810227555 A CN 200810227555A CN 101415013 A CN101415013 A CN 101415013A
- Authority
- CN
- China
- Prior art keywords
- packet
- gtp
- value
- message types
- end marker
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Abstract
The invention provides a method used for marking an End Marker data packet; the method is applied to the switching process of terrestrial radio access network of the universal mobile telecommunications system; a message type value used for marking the End Marker data packet is remained in advance; the message type value in the GTP head of a GTP-U (general packet radio service tunnel protocol user plane) data packet of the general packet radio service tunnel protocol carrying no user data is arranged into the message type value used for marking the End Marker data packet and sent out subsequently. The method can ensure that the End Marker can carry out marking in the GTP Header, leads the subsequent GTP-U data packet receiving terminal to gain the message type value in the GTP Header by the analysis, and leads the receiving terminal to correctly execute the subsequent corresponding flows after the received GTP-U data packet is confirmed as the End Marker date packet.
Description
Technical field
The present invention relates to the communication data identification technology, the method for particularly a kind of identifying endpoint designation (EndMarker) packet.
Background technology
Universal mobile telecommunications system land radio access web (E-UTRAN in evolution, EvolvedUMTS Territorial Radio Access Network) in the handoff procedure, when carrying out data forwarding, gateway (Serving Gateway) makes up and does not carry the End Marker packet of Any user data, source base station (Source eNodeB) to evolution sends, Source eNodeB need pass through general packet wireless service tunnel protocol head (GTP Header, GTP user data channel (the GTP-U of the identification (RNC-ID) analytic GPRS Tunnel Protocol Header) and definite carrying, GTP User DataTunnelling) data are not for carrying the End Marker packet of Any user data, this data carried by data of the preceding commentaries on classics of target BS (Target eNodeB) to evolution, and after commentaries on classics is finished before this data carried by data, this End Marker packet of preceding commentaries on classics; Target eNodeB receives the EndMarker packet that Source eNodeB sends, by the identification (RNC-ID) analytic among the GTP Header and after determining that the GTP-U packet that receives is End Marker packet, start and carry out the step of initialization X2 interface (eNodeB interface) forwarding subscriber data and the rearrangement of S1 interface (MME and eNodeB interface) user data.
At present, in the E-UTRAN handoff procedure, the switching flow that 3G (Third Generation) Moblie standardization collaborative project (3GPP, 3rd Generation Partnership Project) is described is as follows.
The schematic flow sheet of Fig. 1 for switching in the E-UTRAN in existing 3GPP 36.300 agreements, referring to Fig. 1, switching flow comprises in this:
Step 101, the measurement report information that Source eNodeB reports according to subscriber equipment (UE, User Equipment) is initiated to switch after handover decisions, and carries out switching with Target eNodeB, UE and prepare and switch to carry out flow process;
Step 102, Target eNodeB is to mobile management entity (MME, Mobility ManagementEntity) transmit path conversion request (Path Switch Request) message;
In this step, Target eNodeB structure Path Switch Request message, and send to MME after this message encoded, carry downlink tunnel destination node (TEID, the Tunnel Endpoint Identifier) information that Target cell distributes in the message;
Step 103, MME sends user's face update request (User Plane Update Request) message to gateway (Serving Gateway), and notice Serving Gateway translation data transmit path carries descending TEID information in the message;
Step 104, Serving Gateway receives user's face update inquiry information, and the message that receives is decoded; After the downlink data tunnel destination node information and executing downlink path conversion (Switch Downlink Path) of carrying in the message, send End Marker packet to Source eNodeB;
In this step, Serving Gateway sends End Marker packet to Source eNodeB in this carrying after the downlink data path conversion of finishing carrying; End Marker package identification is filled in GTP Header, and End Marker packet does not carry the Any user data.
Step 105, Serving Gateway sends user's face to MME and upgrades response (User PlaneUpdate Response) message, and notice MME finishes the data path conversion and upgrades;
Step 106, MME confirms (Path SwitchRequest Ack) message to Target eNodeB transmit path conversion request;
Step 107, Target eNodeB sends the UE context to Source eNodeB and discharges (UEContext Release) message, and notice Source eNodeB discharges the UE context;
Step 108 after Source eNodeB receives UE Context Release message and End Marker packet, is proceeded data forwarding (Data Forwarding);
In this step, Source eNodeB receives the GTP-U packet, determine also that by the identification (RNC-ID) analytic of filling among the GTP Header this carrying GTP-U packet is an End Marker packet, continue to carry out data forwarding: if the data of having changeed before existing not in the data forwarding buffer memory, this remaining data is changeed before Target eNodeB, after commentaries on classics is finished before with this data carried by data, execution in step 109, and after receiving UE Context Release message, discharge the resource of Source eNodeB side; Need preceding data of changeing if exist in the data forwarding buffer memory, directly execution in step 109 when receiving UE ContextRelease message, discharges the resource of Source eNodeB side.
Step 109, Source eNodeB sends End Marker packet to Target eNodeB, and discharging Source eNodeB resource, Target eNodeB starts X2 interface forwarding subscriber data and S1 interface user data distribution function according to the order of sequence according to the End Marker packet that receives.
In this step, after Source eNodeB finishes commentaries on classics before this data carried by data, before TargeteNodeB, change the GTP-U packet of sign End Marker packet, and release Source eNodeB resource after commentaries on classics is finished before End Marker packet, Target eNodeB receives End Marker packet, by the identification (RNC-ID) analytic among the GTP Header and definite this carrying GTP-U packet is the EndMarker packet, starts these carrying X2 interface forwarding subscriber data (packet) and S1 interface user data (packet) distribution function according to the order of sequence.
So far, switching flow finishes in this.
By as seen above-mentioned, description according to the 3GPP agreement, End Marker package identification is filled in GTPHeader, thereby after eNodeB (Source eNodeB and Target eNodeB) receives the GTP-U packet, by the identification (RNC-ID) analytic among the GTP Header and after determining that this carrying GTP-U packet is End Marker packet, carry out follow-up corresponding flow process.But mode of position, filling value and the filling of how in GTP Header, to fill, to fill for End Marker package identification etc., present 3GPP is not described, and causes GTP-U packet transmitting terminal can't specifically fill the sign of End Marker packet in GTPHeader; After eNodeB receives the GTP-U packet,, can not determine whether current GTP-U packet is End Marker packet, thereby make eNodeB can not carry out follow-up corresponding flow process by resolving the sign that GTP Header fills.
Summary of the invention
In view of this, a main purpose of the present invention is to provide a kind of method of the End of sign Marker packet, End Marker package identification is set in the value of message types of reserving in GTP Header, thereby make eNodeB resolve the GTP-U packet, can be defined as End Marker packet to carry out follow-up corresponding flow process by GTP Header.
For achieving the above object, the invention provides a kind of method of the End of sign Marker packet, be applied to the universal mobile telecommunications system land radio access web handoff procedure of evolution, remain for identifying End Marker data packet message types value in advance in advance, this method comprises:
Not carrying value of message types in the general packet wireless service tunnel protocol user data channel GTP-U packet GTP head of Any user data is set to describedly remain for identifying End Marker data packet message types value in advance and send.
This method further comprises:
Receive described GTP-U packet,, determine that described GTP-U packet is described End Marker packet if resolve value of message types in the GTP head obtain with described to remain for identifying End Marker data packet message types value in advance consistent.
This method further comprises:
After the source base station of evolution determines that described GTP-U packet is described End Marker packet, carry out data forwarding, and after data forwarding is finished, before the target BS of evolution, change described GTP-U packet;
The target BS of evolution receives described GTP-U packet, determines that by the value of message types of resolving in the GTP head GTP-U packet that receives is an End Marker packet, starts the forwarding subscriber data and the flow process of dispatch user data according to the order of sequence.
The value of message types of described reservation specifically comprises: the value of message types of reserving in 3G (Third Generation) Moblie standardization collaborative project 3GPP29.060 agreement or 3GPP 29.274 agreements.
The value of message types of reserving in described 3GPP 29.060 agreements specifically comprises: value of message types is 0, the arbitrary value of message types among 8-15,24-25,38-47,61-69,71-95,106-111,122-127,130-239 and the 242-254.
The value of message types of reserving in described 3GPP 29.274 agreements specifically comprises: value of message types is 0, the arbitrary value of message types among 40-63,68-94,102-127,148-159,162-175,178-191 and the 192-254.
As seen from the above technical solutions, a kind of method that identifies End Marker packet provided by the invention, remain for identifying End Marker data packet message types value in advance in advance, the value of message types that does not carry in the general packet wireless service tunnel protocol user data channel GTP-U packet GTP head of Any user data is set to remain for identifying End Marker data packet message types value in advance, and the GTP-U packet is sent.Guaranteed that End Marker packet can identify in GTP Header, make follow-up middle GTP-U packet receiving terminal to obtain value of message types by resolving GTP Header, after the GTP-U packet that determine to receive is End Marker packet, thereby make the receiving terminal can the follow-up corresponding flow process of correct execution.
Description of drawings
The schematic flow sheet of Fig. 1 for switching in the E-UTRAN in existing 3GPP 36.300 agreements;
Fig. 2 identifies the schematic flow sheet of End Marker packet for the present invention.
Embodiment
For making the purpose, technical solutions and advantages of the present invention clearer, below in conjunction with the accompanying drawings and the specific embodiments the present invention is described in further detail.
The method of sign End Marker packet provided by the invention, in agreement, replenish and reserve sign End Marker data packet message types value in advance, when GTP-U packet transmitting terminal (ServingGateway) sends the GTP-U packet, by sign End Marker data packet message types value is set in the value of message types that keeps at the GTP of GTP-U packet Header, after GTP-U packet receiving terminal (eNodeB) receives the GTP-U packet, by the value of message types among the parsing GTP Header, thereby determine whether the GTP-U packet that receives is End Marker packet.
The GTP Header structure of the GTP-U packet that relates to 3GPP 29.060 agreements and 3GPP 29.274 agreements is that example describes below.For related protocols such as 3GPP 36.300 agreements, can be referring to its related specifications.
Table 1 is the structural representation table of GTP Header in 3GPP 29.060 agreements.
Table 2
In the table 1, Version is 3GPP 29.060 protocol versions;
PT is protocol type (Protocol Type), and 0 presentation protocol type is GTP '; 1 presentation protocol type is GTP;
(
*) for keeping the position, being set to 0, the expression receiving terminal is not assessed this position;
E is extension header type (Extension Header Type) sign, the no extension header of 0 expression, and 1 expression has extension header, if E is 1, then expression comprises the byte sequence number 12 in the table;
S is sequence number (Sequence Number) sign, the no sequence number of 0 expression, and 1 expression has sequence number, comprises the byte sequence number 9 and 10 in the table this moment;
PN is N-PDU number sign, no N-PDU number sign of 0 expression, and 1 expression has sign N-PDU number, comprises the byte sequence number 11 in the table this moment.
In the above-mentioned parameter, protocol version takies three bits, PT, (
*), E, S, PN each take a bit respectively.
Byte 2 is GTP type of message (Message Type) value, describes hereinafter.
Byte 3 to byte 4 is used for the length of sign load (Payload), takies two bytes.
Byte 5 to byte 8 is used for the tunnel destination node sign (TEID, TunnelEndpoint Identifier) of agreement receiving entity.
Byte 9 to byte 10 is used for the sequence number sign.
Byte 11 is used for sign N-PDU number.
Byte 12 is used for next extension header type identification.
In the table 1, the byte that GTP type of message (Message Type) takies can be represented 256 (decimal values) kind message, GTP value of message types signal table in 3GPP 29.060 agreements that its concrete message is shown in Table 2.
Table 2
| Value of message types (decimal system) | Message | GTP-C | GTP-U | GTP′ |
| 0 | Reserve, can not send,, be considered as unknown message if receive | |||
| 1 | Request is responded | X | X | X |
| 2 | The request response | X | X | X |
| … | … | … | … | … |
| 8-15 | Reserve, can not send,, be considered as unknown message if receive | |||
| … | … | … | … | … |
| 24-25 | Reserve, can not send,, be considered as unknown message if receive | |||
| … | … | … | … | … |
| 38-47 | Reserve, can not send,, be considered as unknown message if receive | |||
| … | … | … | … | … |
| 61-69 | Reserve, can not send, if receive, |
| Value of message types (decimal system) | Message | GTP-C | GTP-U | GTP′ |
| Be considered as unknown message | ||||
| 70 | RAN information transmits | X | ||
| 71-95 | Reserve, can not send,, be considered as unknown message if receive | |||
| … | … | … | … | … |
| 106-111 | Reserve, can not send,, be considered as unknown message if receive | |||
| … | … | … | … | … |
| 122-127 | Reserve, can not send,, be considered as unknown message if receive | |||
| … | … | … | … | … |
| 130-239 | Reserve, can not send,, be considered as unknown message if receive | |||
| 240 | Data record transmission request | X | ||
| 241 | Data record migration response | X | ||
| 242-254 | Reserve, can not send,, be considered as unknown message if receive | |||
| 255 | G-PDU | X |
In the table 2, GTP-C represents GTP chain of command data (GTP Control).
Table 3 is the structural representation table of GTP Header in 3GPP 29.274 agreements.
Table 3
In the table 3, Version is a protocol version; T is the given sign of TEID, the no TEID of 0 expression, and 1 expression has TEID, and identifies to byte 8 in byte 5.
S is the sequence number sign, the no sequence number of 0 expression, and 1 expression has sequence number, and the TEID sign is arranged, and identifies to byte 10 in byte 9.
E is the extension header sign, the no extension header of 0 expression; 1 expression has extension header, and the TEID sign is arranged, when S=1, in byte 10 back signs, when S=0, in byte 8 back signs.
FFS is for needing further research (For Further Study), and promptly reserved byte identifies, and current version is for keeping the position.
Similar with table 1, the byte that the GTP type of message in the table 3 (Message Type) takies can be represented 256 kinds of message, GTP value of message types signal table in 3GPP 29.274 agreements that its concrete message is shown in Table 4.
Table 4
| Value of message types (decimal system) | Message | GTP-C | GTP-U |
| 0 | Keep | ||
| 1 | Request is responded | X | X |
| 2 | The request response | X | X |
| … | … | … | … |
| Value of message types (decimal system) | Message | GTP-C | GTP-U |
| 40-63 | Reserve, do not use | ||
| … | … | … | … |
| 68-94 | Reserve, do not use | ||
| … | … | … | … |
| 102-127 | Reserve, do not use | ||
| … | … | … | … |
| 148-159 | Reserve, do not use | ||
| … | … | … | … |
| 162-175 | Reserve, do not use | ||
| … | … | … | … |
| 178-191 | Reserve, do not use | ||
| Other | |||
| 192-254 | Reserve, do not use | ||
| 255 | User face data (load), G-PDL | X |
In above-mentioned table 1～table 4, the structure of GTP Header and the particular type of message thereof also can be respectively referring to 3GPP 29.060 agreements and 3GPP 29.274 agreements.
By as seen above-mentioned, in present that used and the untapped GTP value of message types that table 2, table 4 provide, all do not provide End Marker value of message types.
In table 1 and the table 3, the sign position that keeps among the GTP Header comprises the reservation position to localization, for example, and (*), the Message Type position of sign such as FFS position and byte 2.
For with GTP Header in give the sign position of localization, for example, the effect of S, E equipotential is consistent and the continuity of agreement, among the present invention, the sign position of End Marker packet does not take the reservation position to localization, promptly do not take (
*) or the sign position of FFS, utilize the value of message types that keeps among the Message Type or reserve to identify End Marker packet.
The value of message types that " reserving; can not send; if receive; be considered as unknown message " that the concrete value of message types ginseng that keeps is shown in Table 2 is corresponding and " reserving; do not use " the corresponding value of message types shown in the table 4, among the present invention, for 3GPP 29.060 agreements, can be according to predetermined strategy, as the definition value of message types is 0 in 3GPP 29.060 agreements in advance, arbitrary value of message types among 8-15,24-25,38-47,61-69,71-95,106-111,122-127,130-239 and the 242-254 identifies End Marker packet; For the 3GPP29.274 agreement, can be from 0, choose arbitrary value of message types 40-63,68-94,102-127,148-159,162-175,178-191 and the 192-254 and identify End Marker packet.
In the present embodiment, use value of message types 254 to identify End Marker packet.
Table 3 is the GTP value of message types signal table of the present invention's default sign End Marker packet in 3GPP 29.060 agreements.
Table 4
| Value of message types (decimal system) | Message | GTP-C | GTP-U | GTP′ |
| 0-241 | … | … | … | … |
| 242-253 | Reserve, can not send,, be considered as unknown message if receive | |||
| 254 | End?Marker | X | ||
| 255 | G-PDU | X |
In the table 5, value of message types 254 sign GTP-U data are End Marker packet.
Table 6 is the GTP value of message types signal table of the present invention's default sign End Marker packet in 3GPP 29.274 agreements.
Table 5
| Value of message types (decimal system) | Message | GTP-C | GTP-U |
| 0-191 | … | ||
| Other | |||
| 192-253 | Reserve, do not use | ||
| 254 | End?Marker | X | |
| 255 | User face data (load), G-PDU | X |
In the table 6, the End Marker packet of value of message types 254 sign GTP-U data.
Like this, by in 3GPP 29.060 agreements, 3GPP 29.274 agreements, replenishing sign EndMarker data packet message types value, when GTP-U packet transmitting terminal sends the GTP-U data of sign End Marker packet, only need the Message Type value among the GTP Header to be set to 254, and need not carry the Any user data; GTP-U packet receiving terminal receives the GTP-U data, resolves after the value of obtaining the Message Type among the GTP Header is 254, i.e. the GTP-U data of this reception of decidable are End Marker packet, thereby can make receiving terminal carry out follow-up corresponding flow process.
Fig. 2 identifies the schematic flow sheet of End Marker packet for the present invention, and referring to Fig. 2, this flow process comprises:
Step 201 is provided with the Message Type value that identifies the EndMarker packet in advance in the Message Type value that the GTP-U packet is reserved;
In this step, specifically, in the value of message types that related protocols such as 3GPP 29.060 agreements or 3GPP 29.274 agreements are reserved, remain for identifying End Marker data packet message types value in advance in advance, be used to identify End Marker packet.
In the present embodiment, supplementary provisions Message Type value is 254 in value of message types one hurdle that the GTP Header of 3GPP 29.060 agreements or 3GPP 29.274 agreements reserves, referring to table 5 and table 6, being used to identify these GTP-U data is End Marker packet, and these GTP-U data are not carried the Any user data.
In the practical application, the Message Type value of also can replenishing regulations in agreement is sign End Marker data packet message types value for arbitrary Message Type value of reserving.
In this step, Message Type value among GTP-U packet transmitting terminal (Serving Gateway) the GTP-U packet GTP Header is set to remain in advance identifying the Message Type value 254 of End Marker packet, do not carry the Any user data, and this GTP-U packet is sent.
So far, realized sign End Marker packet in the GTP-U packet that sends, the flow process that the present invention identifies End Marker packet finishes.
In follow-up, further execution in step 203.
Step 203 receives the GTP-U data, carries out corresponding operating according to resolving the MessageType value that comprises among the GTP Header.
In this step, eNodeB receives the GTP-U data, resolve the Message Type value among the GTP Header, if resolving the Message Type value of obtaining is 254, show that then these GTP-U data are the EndMarker packet, after eNodeB is known as End Marker packet, eNodeB knows that the GTP-U data of reception are that operation is similar behind the End Marker packet in operation of carrying out and the 3GPP36.300 agreement, be after Source eNodeB is End Marker packet by the GTP-U packet of resolving the definite reception of GTP Header, carry out data forwarding, and after data forwarding is finished, before TargeteNodeB, change this End Marker packet; Target eNodeB receives End Marker packet, by resolving the sign among the GTP Header and determining that the data that receive are End Marker packet, starts the forwarding subscriber data and the flow process of dispatch user data according to the order of sequence.
As seen from the above-described embodiment, a kind of method that identifies End Marker packet provided by the invention, keeping protocol conformance, under the prerequisite of continuity and utilizability, by to 3GPP 29.060 agreements, the value of message types that 3GPP 29.274 agreements are reserved replenishes, sign End Marker data packet message types value is set in the value of message types that the GTPHeader of GTP-U packet keeps, guaranteed that End Marker packet can identify in GTP Header, and End Marker packet is set does not carry the Any user data, make GTP-U packet receiving terminal obtain value of message types among the GTPHeader by parsing, after the GTP-U packet that determine to receive is End Marker packet, thereby make the receiving terminal can the follow-up corresponding flow process of correct execution.
More than lift preferred embodiment; the purpose, technical solutions and advantages of the present invention are further described; institute is understood that; the above only is preferred embodiment of the present invention; not in order to restriction the present invention; within the spirit and principles in the present invention all, any modification of being done, be equal to replacement, improvement etc., all should be included within protection scope of the present invention.
Claims (6)
1, a kind of method of identifying endpoint designation End Marker packet, be applied to the universal mobile telecommunications system land radio access web handoff procedure of evolution, it is characterized in that remain for identifying End Marker data packet message types value in advance in advance, this method comprises:
Not carrying value of message types in the general packet wireless service tunnel protocol user data channel GTP-U packet GTP head of Any user data is set to describedly remain for identifying End Marker data packet message types value in advance and send.
2, the method for claim 1, it is characterized in that, further comprise: receive described GTP-U packet, if resolve value of message types in the GTP head obtain with described to remain for identifying EndMarker data packet message types value in advance consistent, determine that described GTP-U packet is described End Marker packet.
3, method as claimed in claim 2 is characterized in that, this method further comprises:
After the source base station of evolution determines that described GTP-U packet is described End Marker packet, carry out data forwarding, and after data forwarding is finished, before the target BS of evolution, change described GTP-U packet;
The target BS of evolution receives described GTP-U packet, determines that by the value of message types of resolving in the GTP head GTP-U packet that receives is an End Marker packet, starts the forwarding subscriber data and the flow process of dispatch user data according to the order of sequence.
4, the method for claim 1 is characterized in that, the value of message types of described reservation specifically comprises: the value of message types of reserving in 3G (Third Generation) Moblie standardization collaborative project 3GPP 29.060 agreements or 3GPP 29.274 agreements.
5, method as claimed in claim 4, it is characterized in that the value of message types of reserving in described 3GPP 29.060 agreements specifically comprises: value of message types is 0, the arbitrary value of message types among 8-15,24-25,38-47,61-69,71-95,106-111,122-127,130-239 and the 242-254.
6, method as claimed in claim 4, it is characterized in that the value of message types of reserving in the described 3GPP29.274 agreement specifically comprises: value of message types is 0, the arbitrary value of message types among 40-63,68-94,102-127,148-159,162-175,178-191 and the 192-254.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2008102275554A CN101415013B (en) | 2008-11-27 | 2008-11-27 | Method for identifying endpoint designation data packet |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2008102275554A CN101415013B (en) | 2008-11-27 | 2008-11-27 | Method for identifying endpoint designation data packet |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101415013A true CN101415013A (en) | 2009-04-22 |
| CN101415013B CN101415013B (en) | 2011-09-28 |
Family
ID=40595325
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2008102275554A Expired - Fee Related CN101415013B (en) | 2008-11-27 | 2008-11-27 | Method for identifying endpoint designation data packet |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101415013B (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102164364A (en) * | 2011-05-10 | 2011-08-24 | 电信科学技术研究院 | GTP-U (tunneling protocol for user plane) tunnel error processing method and device |
| WO2013016843A1 (en) * | 2011-08-02 | 2013-02-07 | Telefonaktiebolaget L M Ericsson (Publ) | Implementation of packet data service in a mobile communication network |
| CN110753076A (en) * | 2018-07-24 | 2020-02-04 | 中国移动通信有限公司研究院 | Data sending and receiving method, device and storage medium |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5408419A (en) * | 1992-04-14 | 1995-04-18 | Telefonaktiebolaget L M Ericsson | Cellular radiotelephone system signalling protocol |
| CN100372390C (en) * | 2004-06-18 | 2008-02-27 | 华为技术有限公司 | Retransmission method of protocol data unit |
-
2008
- 2008-11-27 CN CN2008102275554A patent/CN101415013B/en not_active Expired - Fee Related
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102164364A (en) * | 2011-05-10 | 2011-08-24 | 电信科学技术研究院 | GTP-U (tunneling protocol for user plane) tunnel error processing method and device |
| WO2012152147A1 (en) * | 2011-05-10 | 2012-11-15 | 电信科学技术研究院 | Gtp-u tunnel error processing method and device |
| CN102164364B (en) * | 2011-05-10 | 2014-01-08 | 电信科学技术研究院 | GTP-U (tunneling protocol for user plane) tunnel error processing method and device |
| WO2013016843A1 (en) * | 2011-08-02 | 2013-02-07 | Telefonaktiebolaget L M Ericsson (Publ) | Implementation of packet data service in a mobile communication network |
| US9094852B2 (en) | 2011-08-02 | 2015-07-28 | Telefonaktiebolaget L M Ericsson (Publ) | Implementation of packet data service in a mobile communication network |
| CN110753076A (en) * | 2018-07-24 | 2020-02-04 | 中国移动通信有限公司研究院 | Data sending and receiving method, device and storage medium |
| CN110753076B (en) * | 2018-07-24 | 2022-04-01 | 中国移动通信有限公司研究院 | Data sending and receiving method, device and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101415013B (en) | 2011-09-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20220174759A1 (en) | Method and apparatus for operating wireless communication system having separated mobility management and session management | |
| US11621916B2 (en) | Information transmission method and device in IAB architecture | |
| US20210289402A1 (en) | Radio access network handover method, base station, and communication method of the base station | |
| CN113411850B (en) | Switching method and device | |
| EP3627900B1 (en) | Bearer handover control method and serving gateway | |
| CN109005562B (en) | Method, device and system for transmitting data | |
| AU2008227506B2 (en) | Network registration method, mobile station and subscriber information management server | |
| US9713188B2 (en) | Service data transmission method and system, and device | |
| CN104902580B (en) | Method for supporting data forwarding in small cell system | |
| US20030153296A1 (en) | Method for transferring a tunnel between nodes in gprs system | |
| US8867471B2 (en) | Method, device, and system for reporting radio access network element information | |
| CN102595647B (en) | Network system and network apparatus | |
| KR20110092875A (en) | Wireless communication system and method for establishing connection between user equipment and mobility management entity | |
| JP6888099B2 (en) | Multi-connection communication methods, devices, and terminals | |
| CN101415013B (en) | Method for identifying endpoint designation data packet | |
| US10397805B2 (en) | Communication device, communication system, and control method | |
| CN103582161A (en) | Method for transmitting data based on LTE system relay node | |
| CN102547867A (en) | Public bearing building method and uplink multipoint-to-point GTP tunnel transmission method | |
| US20150237458A1 (en) | Mobile communication system, data communication method, gateway device and base station | |
| CN101610462B (en) | Data message sending method, device and communication system | |
| CN116326168A (en) | Signaling switching scheme in wireless communication | |
| CN105704763A (en) | Network switching method and mobile management entity | |
| TW202420855A (en) | Data transmission method and apparatus |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| ASS | Succession or assignment of patent right |
Owner name: CHINA POTEVIO CO., LTD. Free format text: FORMER OWNER: PUTIAN IT TECH INST CO., LTD. Effective date: 20130916 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20130916 Address after: 100080, No. two, 2 street, Zhongguancun science and Technology Park, Beijing, Haidian District Patentee after: China Potevio Information Industry Co., Ltd. Address before: 100080 Beijing, Haidian, North Street, No. two, No. 6, No. Patentee before: Putian IT Tech Inst Co., Ltd. |
|
| ASS | Succession or assignment of patent right |
Owner name: PUTIAN IT TECH INST CO., LTD. Free format text: FORMER OWNER: CHINA POTEVIO CO., LTD. Effective date: 20131128 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20131128 Address after: 100080 Beijing, Haidian, North Street, No. two, No. 6, No. Patentee after: Putian IT Tech Inst Co., Ltd. Address before: 100080, No. two, 2 street, Zhongguancun science and Technology Park, Beijing, Haidian District Patentee before: China Potevio Information Industry Co., Ltd. |
|
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110928 Termination date: 20201127 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |