Wireless usage 무선으로 사용


Wi-Fi를 통해서 단말을 adb 접속시키는 방법

  1. Connect your Android device and adb host computer to a common Wi-Fi network accessible to both. We have found that not all access points are suitable; you may need to use an access point whose firewall is configured properly to support adb.

    Note: If you are attempting to connect to a Wear device, force it to connect to Wi-Fi by shutting off Bluetooth on the phone connected to it.

  2. Connect the device to the host computer with a USB cable. USB 케이블을 사용해서 디바이스와 컴퓨터 연결
  3. Set the target device to listen for a TCP/IP connection on port 5555. 타켓 디바이스를 포트 5555를 통해 TCP/IP 접속하도록 세팅

    $ adb tcpip 5555
    
  4. Disconnect the USB cable from the target device. USB 케이블 접속을 해제
  5. Find the IP address of the Android device. For example, on a Nexus device, you can find the IP address at Settings >About tablet (or About phone) > Status > IP address. Or, on an Android Wear device, you can find the IP address atSettings > Wi-Fi Settings > Advanced > IP address. 안드로드의 IP 주소 확인 방법
  6. Connect to the device, identifying it by IP address. 디바이스 IP 주소를 입력하여 디바이스 연결

    $ adb connect <device-ip-address>
    
  7. Confirm that your host computer is connected to the target device 타겟 디바이스가 연결되었는지 확인:

    $ adb devices
    List of devices attached
    <device-ip-address>:5555 device
    

You're now good to go!

If the adb connection is ever lost 만약 연결이 끊어진다면 :

  1. Make sure that your host is still connected to the same Wi-Fi network your Android device is. 디바이스와 호스트가 동일한 Wi-Fi 사용중인지 확인.
  2. Reconnect by executing the "adb connect" step again. "adb connect" 를 재 실시
  3. Or if that doesn't work, reset your adb host 위 내용 실시에도 연결아 안되는 경우 서버 종료 후 재실시:

    adb kill-server
    
    and then start over from the beginning.


http://developer.android.com/intl/ko/tools/help/adb.html


'Japan > Work As Tester' 카테고리의 다른 글

adb shell 명령어  (0) 2016.03.18
VoLTE관련  (0) 2016.03.18
디바이스와 adb 무선으로 사용하도록 세팅  (0) 2016.03.18
ADB 명령어(1)  (0) 2016.03.18
DDMS(Dalvik Debug Monitoring Service)  (0) 2016.03.18
DUT  (0) 2016.03.09


adb devices

휴대폰의 adb인식이 되어있는지 확인할때 사용하는 명령어

adb 서버가 인식한 휴대폰과 에뮬레이터 목록을 보여준다.

연결된 devices의 TCP/IP 포트 번호를 알아낼 때 도움이 된다.


다른 명령어를 사용할 때, -s나 -e 옵션은 여러 개의 장치를 연결했을 때 특정한 디바이스를 지정할 때 사용한다.


adb remount

권한 얻기

/system 파티션을 read/write 가능하도록 다시 마운트(remount)해줍니다

 

adb shell

타겟 시스템의 쉘에 연결하고 # 프롬프트를 띄운다. 

쉘은 간소한 유닉스 쉘 같아서 간단한 명령으로 타겟 시스템을 탐색하고 수정할 수 있다.

테스트 시, 소프트웨어가 엔지니어버전인 경우는 

Root권한도 취득한 상태여서 사용할 수 있는 기능이 많음 


예) 여러 단말기 중에 하나를 선택해서 접속할 때,

adb -s emulator-5554 shell


adb install [-l][-r] file_spec

app을 설치하거나 재설치할 때 사용한다.

-l : 다른 장치로 복사돼 넘어가는 것을 막는다.

-r: 이미 존재하는 app 사용자 데이터를 지우지 않은 채 어플리케이션만 재설치 하는 옵션.

file_spec: 설치할 app의 .apk 파일

(경로 입력하지 귀찮으면 명령창에 설하고 싶은 apk를 드래그앤드롭으로 넣으면 자동으로 경로 입력 됨 )


예) 파일 설치시

adb install c:\download\HangulKeyboard.apk

 

adb uninstall [-k] package

패키지 이름을 가진 app을 제거하다. 

-k : app의 데이터를 보존한다.

package: 패키지의 전체 경로, .apk 확장자는 빼야 한다.


예) 패키지 삭제시

adb unstall com.falinux.android.hello

 

adb push local remote

개발자 컴퓨터에 있는 local이란 이름을 가진 파일을 타겟 시스템에 remote란 이름으로 복사한다.

예) com.falinux.android.rose.apk 파일을 안드로이드 기기 /data/app/ 폴더 안으로 집어넣을 때,

adb push c:\com.falinux.android.rose.apk /data/app/


 - 사인 문제로 재설치 안될 경우 오버라이트로 설치

  adb -d push test.apk /system/app


adb pull remote local

타겟 시스템에 있는 remote라는 파일을 개발자 컴퓨터에 local이란 이름으로 복사한다.


예) 안드로이드 기기 /data/app/com.falinux.android.rose.apk 파일을 C 드라이브로 가져올 때,

adb pull /data/app/com.falinux.android.rose.apk c:\com.falinux.android.rose.apk

 

adb reboot

안드로이드 시스템을 리부팅 시킨다.

 

adb kill-server

adb 에 문제가 있을 경우, adb를 종료시킨다.

 

adb start-server

종료된 adb를 실행 시킨다.


참조 출처

http://forum.falinux.com/zbxe/index.php?document_srl=533523&mid=android

http://developer.android.com/intl/ko/tools/help/adb.html

'Japan > Work As Tester' 카테고리의 다른 글

VoLTE관련  (0) 2016.03.18
디바이스와 adb 무선으로 사용하도록 세팅  (0) 2016.03.18
ADB 명령어(1)  (0) 2016.03.18
DDMS(Dalvik Debug Monitoring Service)  (0) 2016.03.18
DUT  (0) 2016.03.09
IMS/SIP - Message List  (0) 2016.03.09

DDMS(Dalvik Debug Monitoring Service)

회사 보안상 PC에서 MPT 사용이 되지 않도록 되어있어서,

DDMS를 사용하여 휴대폰 저장소확인을 진행


사용하기 위해서는 ADB사용을 위해 환경 변수를 추가하였듯이, 

DDMS가 들어있는 폴더를 찾아서 환경변수 추가하여 

PC  재기동 &, 

단말 연결하여 인식시킨 후

명령창에 DDMS를 치면 사용 가능! 


'Japan > Work As Tester' 카테고리의 다른 글

디바이스와 adb 무선으로 사용하도록 세팅  (0) 2016.03.18
ADB 명령어(1)  (0) 2016.03.18
DDMS(Dalvik Debug Monitoring Service)  (0) 2016.03.18
DUT  (0) 2016.03.09
IMS/SIP - Message List  (0) 2016.03.09
VoLTE용어정리  (0) 2016.03.09
DUT

device under test 시험중 장비
지금 내 프로젝트에서는 테스트 단말을 의미

'Japan > Work As Tester' 카테고리의 다른 글

ADB 명령어(1)  (0) 2016.03.18
DDMS(Dalvik Debug Monitoring Service)  (0) 2016.03.18
DUT  (0) 2016.03.09
IMS/SIP - Message List  (0) 2016.03.09
VoLTE용어정리  (0) 2016.03.09
자주 등장하는 프로토콜 정리  (0) 2016.03.09

1. Request Message

 

Followings are very Basic SIP message based on RFC 3261.

 

Request Message

Description

REGISTER

A Client use this message to register an address with a SIP server

INVITE

A User or Service use this message to let another user/service participate in a session. The body of this message would include a description of the session to which the callee is being invited.

ACK

This is used only for INVITE indicating that the client has received a final response to an INVITE request

CANCELThis is used to cancel a pending request
BYEA User Agent Client use this message to terminate the call
OPTIONS

This is used to query a server about its capabilities

INFOThis is used for mid session signaling

 

Followings are kind of extended message defined by various RFC

Request Message

Description

MESSAGE

Usually used to send Standalone Message (like SMS). RFC 3428
SUBSCRIBE

used to request asynchronous notification of an event or set of events at a later time. RFC 6665

NOTIFY

used to notify a SIP node that an event that has been requested by an earlier SUBSCRIBE method has occurred. RFC 6665

UPDATE

used for a client to update parameters of a session (such as the set of media streams and their codecs). RFC 3311

PRACK

plays the same role as ACK, but this is used for provisional responses. RFC 3262

PUBLISHused for publication of presence information. RFC 3093

 

 

2. Response Message

 

This is based on RFC 3261.

Code

Category

Description

1xxProvisional

The request has been received and processing is continuing

2xxSuccess

An ACK, to indicate that the action was successfully received, understood, and accepted.

3xxRedirection

Further action is required to process this request

4xxClient Error

The request contains bad syntax and cannot be fulfilled at this server

5xxServer Error

The server failed to fulfill an apparently valid request

6xxGlobal Failure

The request cannot be fulfilled at any server

 

 

Code

Message

Description

1xx

100

Trying

This response indicates that the request has been received by the next-hop server and that some unspecified action is being taken on behalf of this call (for example, a database is being consulted).

This response, like all other provisional responses, stops retransmissions of an INVITE by a UAC.  The 100 (Trying) response is different from other provisional responses, in that it is never forwarded upstream by a stateful proxy.

Ref : RFC 3261 21.1.1 100 Trying

 

180

Ringing

The UA receiving the INVITE is trying to alert the user.  This response MAY be used to initiate local ringback

Ref : RFC 3261 21.1.2 180 Ringing

 

181

Call Is Being Forwarded

A server MAY use this status code to indicate that the call is being forwarded to a different set of destinations

Ref : RFC 3261 21.1.3 181 Call Is Being Forwarded

 

182

Queued

The called party is temporarily unavailable, but the server has decided to queue the call rather than reject it.  When the callee becomes available, it will return the appropriate final status response. The reason phrase MAY give further details about the status of the call, for example, "5 calls queued; expected waiting time is 15 minutes".  The server MAY issue several 182 (Queued) responses to update the caller about the status of the queued call.

Ref : RFC 3261 1.1.4 182 Queued

 

183

Session Progress

This response is used to convey information about the progress of the call that is not otherwise classified.  The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress.

Ref : RFC 3261 21.1.5 183 Session Progress

2xx

200

OK

The request has succeeded.  The information returned with the response depends on the method used in the request

Ref : RFC 3261 21.2.1 200 OK

3xx

300

Multiple Choices

The address in the request resolved to several choices, each with its own specific location, and the user (or UA) can select a preferred communication end point and redirect its request to that location.

 

The response MAY include a message body containing a list of resource characteristics and location(s) from which the user or UA can choose the one most appropriate, if allowed by the Accept request header field.  However, no MIME types have been defined for this message body.

Ref : RFC 3261 21.3.1 300 Multiple Choices

 

301

Moved Permanently

The user can no longer be found at the address in the Request-URI, and the requesting client SHOULD retry at the new address given by the Contact header field.  The requestor SHOULD update any local directories, address books, and user location caches with this new value and redirect future requests to the address(es) listed.

Ref : RFC 3261 21.3.2 301 Moved Permanently

 

302

Moved Temporarily

The requesting client SHOULD retry the request at the new address(es) given by the Contact header field (Section 20.10).  The Request-URI of the new request uses the value of the Contact header field in the response

Ref : RFC 3261 21.3.3 302 Moved Temporarily

 

305

Use Proxy

The requested resource MUST be accessed through the proxy given by the Contact field.  The Contact field gives the URI of the proxy.The recipient is expected to repeat this single request via the proxy.  305 (Use Proxy) responses MUST only be generate by UASs

Ref : RFC 3261 21.3.4 305 Use Proxy

 

380

Alternative Service

The call was not successful, but alternative services are possible. The alternative services are described in the message body of the response.  Formats for such bodies are not defined here, and may be the subject of future standardization

Ref : RFC 3261 21.3.5 380 Alternative Service

4xx

400

Bad Request

The request could not be understood due to malformed syntax.  The Reason-Phrase SHOULD identify the syntax problem in more detail, for example, "Missing Call-ID header field".

Ref : RFC 3261 21.4.1 400 Bad Request

 

401

Unauthorized

This indicate that Registra wants to go through Authentication Process

(see Registration with Authentication for details)

 

402

Payment Required

 

 

403

Forbidden

This indicate that a forbidden request has arrived.

For example, REGISTER message with wrong parameters has arrived. (e.g, the ueid or domain name or realm domain is not the one that CSCF is expecting. In this case, CSCF send 403 right after it got REGISTER message).

 

P-CSCF check if the private user identity conveyed in the Authorization header field of the protected REGISTER request is the same as the private user identity which was previously challenged or authenticated. If the private user identities are different, the P-CSCF shall reject the REGISTER request by returning a 403 response.(TS 24.229)

 

If the P-CSCF detect that the Request-URI of the initial request for a dialog, or a standalone transaction, or an unknown method does not match any one of the emergency service identifiers in the associated lists, the P-CSCF shall reject the request by returning a 403 to UE (TS 24.229)

When the I-CSCF recieves a REGISTER request, the I-CSCF shall verify whether or not it has arrived from a trusted domain. If the request has not arrived from a trusted domain, the I-CSCF shall complete the processing of the request by responding with 403(TS 24.229)

 

404

Not Found

The server has definitive information that the user does not exist at the domain specified in the Request-URI.  This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request.

Ref : RFC 3261 21.4.5 404 Not Found

 

405

Method Not Allowed

The method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI. The response MUST include an Allow header field containing a list of valid methods for the indicated address.

Ref : RFC 3261 21.4.6 405 Method Not Allowed

 

406

Not Acceptable

The resource identified by the request is only capable of generating response entities that have content characteristics not acceptable according to the Accept header field sent in the request.

Ref : RFC 3261 21.4.7 406 Not Acceptable

 

407

Proxy Authentication Required

 

 

408

Request Timeout

The server could not produce a response within a suitable amount of time, for example, if it could not determine the location of the user in time.  The client MAY repeat the request without modifications at any later time.

Ref : RFC 3261 21.4.9 408 Request Timeout

 

410

Gone

 

 

413

Request Entity Too Large

 

 

414

Request-URI Too Long

 

 

415

Unsupported Media Type

 

 

416

Unsupported URI Scheme

 

 

420

Bad Extension

 

 

421

Extension Required

 

 

423

Interval Too Brief

This error indicates that the same messages was received multiple times with two short interval. (E.g, An UA send SIP:REGISTER message twice with very short interval and the Registra would send 423)

The server is rejecting the request because the expiration time of the resource refreshed by the request is too short.  This response can be used by a registrar to reject a registration whose Contact header field expiration time was too small.

You may reduce the chance of this error by tweaking Min-Expires header

Ref : RFC 3261 21.4.17 423 Interval Too Brief

 

480

Temporarily Unavailable

 

 

481

Call/Transaction Does Not Exist

 

 

482

Loop Detected

 

 

483

Too Many Hops

 

 

484

Address Incomplete

 

 

485

Ambiguous

 

 

486

Busy Here

 

 

487

Request Terminated

 

 

488

Not Acceptable Here

SDP offer conveyed in a SIP response contained parameters which are not allowed according to the local policy(TS 24.229)

 

491

Request Pending

 

 

493

Undecipherable

 

5xx

500

Server Internal Error

The server encountered an unexpected condition that prevented it from fulfilling the request.  The client MAY display the specific error condition and MAY retry the request after several seconds. If the condition is temporary, the server MAY indicate when the client may retry the request using the Retry-After header field.

If Retry-After is set to be specific value, UE should retry after the specified time and if Retry-After is not set, UE is expected to retry in around 30 sec at the first retry and with extended back-off time.

Ref : RFC 3261 21.5.1 500 Server Internal Error

 

501

Not Implemented

 

 

502

Bad Gateway

 

 

503

Service Unavailable

radio/bearer inferface resources are no longer available (TS 24.229)

the signaling bearer is no longer available (TS 24.229)

 

UE is requesting some service which cannot be supported.

 

When this happens, UE normally retry the request.

If Retry-After is set to be specific value, UE should retry after the specified time and if Retry-After is not set, UE is expected to retry in around 30 sec at the first retry and with extended back-off time.

 

504

Server Time-out

 

 

505

Version Not Supported

 

 

513

Message Too Large

 

6xx

600

Busy Everywhere

 

 

603

Decline

 

 

604

Does Not Exist Anywhere

 

 

606

Not Acceptable

 

 

 

출처 : http://www.sharetechnote.com/

'Japan > Work As Tester' 카테고리의 다른 글

DDMS(Dalvik Debug Monitoring Service)  (0) 2016.03.18
DUT  (0) 2016.03.09
IMS/SIP - Message List  (0) 2016.03.09
VoLTE용어정리  (0) 2016.03.09
자주 등장하는 프로토콜 정리  (0) 2016.03.09
SRVCC의 종류  (0) 2016.03.09

VoLTE를 이해해가 위한 용어정리

IMS:  IP Multimedia Subsystem

SIP: Session Initiation Protocol

SDP: Session Description Protocol

CSCF: Call Session Control Function

HSS: Home Subscriber Server

AS: Application Server

VoLTE: Voice Over LTE

P-CSCF: Proxy CSCF

I-CSCF: Interrogationg CSCF

S-CSCF: Serving CSCF

AKA: Authetication and Key Agreement

AM: Acknowledged Mode

TM: Transparent Mode

EMM: EPS Mobility Management

ESM: EPS Session Management

EPC: Evolved Packet Core

IMPU: IP Multimedia Public Identity

PCRF: Policy and Charging Rules Function

PRACK: Provisional(일시적인) Response ACK

RoHC: Robust Header Compression

URI: Uniform Resource Identifer

'Japan > Work As Tester' 카테고리의 다른 글

DUT  (0) 2016.03.09
IMS/SIP - Message List  (0) 2016.03.09
VoLTE용어정리  (0) 2016.03.09
자주 등장하는 프로토콜 정리  (0) 2016.03.09
SRVCC의 종류  (0) 2016.03.09
SRVCC  (0) 2016.03.09

응용 계층

SIP(Session Initiation Protocol): 세션 개시 프로토콜은 IETF에서 정의한 시그널링 프로토콜로 음성과 화상 통화 같은 멀티미디어 세션을 제어하기 위해 널리 사용되며, 인터넷 상에서 통신하고자 하는 지능형 단말(전화, 인터넷 콘퍼런스, 인스턴트 메신저 등)들이 서로를 식별하여 그 위치를 찾고, 그들 상호 간에 멀티미디어 통신 세션을 생성하거나 삭제 또는 수정하기 위한 절차를 명시한 응용 계층의 시그널링 프로토콜이다. 2000년 11월 SIP는 셀룰러 시스템에서 IP 기반 스트리밍 멀티미디어 서비스를 위한 3GPP 시그널링 프로토콜과 IP 멀티미디어 서브시스템 (IMS) 구조로 채택되었다.

RTP(Real-time Transport Protocol): 실시간 전송 프로토콜은 IP 네트워크를 통해 오디오와 비디오를 전달하기 위한 표준화된 패킷 포맷을 정의한다.

SRTP(Secure Real-time Transport Protocol)

SDP(Session Description Protocol):세션 기술 프로토콜은 스트리밍 미디어의 초기화 인수를 기술하기 위한 포맷이다. SDP는 Session Announcement Protocol (SAP)의 한 부분으로 시작되었지만, RTP, RTSP, SIP 와 멀티캐스트 세션을 기술하기 위한 단독 포맷 등의 결합을 위한 가능성이 확인되었다.


출처: 위키

'Japan > Work As Tester' 카테고리의 다른 글

IMS/SIP - Message List  (0) 2016.03.09
VoLTE용어정리  (0) 2016.03.09
자주 등장하는 프로토콜 정리  (0) 2016.03.09
SRVCC의 종류  (0) 2016.03.09
SRVCC  (0) 2016.03.09
[설정]ADB 코멘드 사용 설정  (0) 2016.03.05

SRVCC의 종류 

aSRVCC: Packet switched to Circuit Switched call transfer during Alerting Phase

bSRVCC: SRVCC before ringing

vSRVCC: SRVCC for video call

rSRVCC:r everse SRVCC HO from CS call to PS IMS

eSRVCC: enhanced SRVCC           

   Support of mid-call feature during SRVCC handover (eSRVCC)

   Support of SRVCC PS-CS transfer of a call in alerting phase (aSRVCC)


SRVCC VS eSRVCC 


참조 

http://www.sharetechnote.com/html/Handbook_LTE_SRVCC.html

  →Protocol Sequence Example 도 있음!

www.exfo.com/library/technical-resources/webinars/testing-ims-volte-esrvcc

  →SRVCC,eSRVCC관련 강의

'Japan > Work As Tester' 카테고리의 다른 글

VoLTE용어정리  (0) 2016.03.09
자주 등장하는 프로토콜 정리  (0) 2016.03.09
SRVCC의 종류  (0) 2016.03.09
SRVCC  (0) 2016.03.09
[설정]ADB 코멘드 사용 설정  (0) 2016.03.05
EVS란  (2) 2016.02.26

SRVCC(Single Radio Voice Call Continuity), 

즉 단일무선음성통화연속 기술은,

LTE의 패킷 스위치 도메인(PS)에서 

2G와 3G에서 운영되는 회로 스위치 방식(CS) 음성 네트워크로 이동하는 경우,

통화 세션을 유지시켜 주는 기술이다. 


상세 내용은 하기 참조! 

 

SRVCC - Single Radio Voice call Continuity is a level of functionality that is required within VoLTE systems to enable the packet domain calls on LTE to be handed over to legacy circuit switched voice systems like GSM, UMTS and CDMA 1x in a seamless manner.

As LTE systems deploy VoLTE coverage will be limited and it is anticipated that it will be many years before complete LTE coverage will be available.

As a result it is necessary for operators to have a system whereby this complicated handover can be accommodated in a seamless fashion. This scheme needs to be in place as soon as they start to deploy VoLTE.

What is SRVCC?

SRVCC, Single radio Voice Call Continuity, is a scheme that enables Inter Radio Access Technology, Inter RAT handover as well as a handover from packet data to circuit switched data voice calls.

By using SRVCC operators are able to make the handovers while maintaining existing quality of service, QoS and also ensuring that call continuity meets the critical requirements for emergency calls.

Some ideas for handover require that the handset has two active radios to facilitate handover. This is not ideal because it requires additional circuitry to enable the two radios to be active simultaneously and it also adds considerably to battery drain.

The SRVCC requires only a single active radio in the handset and requires some upgrades to the supporting network infrastructure.

SRVCC network architecture

The concept for SRVCC was originally included in the 3GPP specification Release 8. Since then it has evolved to take account of the various issues and changing requirements. As a result GSMA recommends that 3GPP Rel 10 or later is implemented as this ensures a considerably lower level of voice interruption and dropped calls.

The network upgrades required to the cellular network are needed in both the LTE network and that of the legacy network or networks. SRVCC requires that software upgrades are required to the MSS - Mobile SoftSwitch subsystem in the legacy MSC - Mobile Switching Centre, the IMS subsystem and the LTE/EPC subsystem. No upgrades are required for the radio access network of the legacy system, meaning that the majority of the legacy system remains unaffected.

The upgrades required for the MSC are normally relatively easy to manage. The MSC is normally centrally located and not dispersed around the network, and this makes upgrades easier to manage. If they are not easily accessible then a new dedicated MSC can be used that has been upgraded to handles the SRVCC requirements.

How SRVCC works

The SRVCC implementation controls the transfer of calls in both directions.


LTE to legacy network handover
Handover from LTE to the legacy network is required when the user moves out of the LTE coverage area. Using SRVCC, the handover is undertaken in two stages.

  • Radio Access Technology transfer:   The handover for the radio access network and this is a well-established protocol that is in use for transfers from 3G to 2G for example.
  • Session transfer:   The session transfer is the new element that is required for SRVCC. It is required to move the access control and voice media anchoring from the Evolved Packet Core, EPC of the packet switched LTE network to the legacy circuit switched network.

During the handover process the CSCF(Call Session Control Function) within the IMS architecture maintains the control of the whole operation.

Diagram showing how SRVCC operates in VoLTE handovers
Voice handover using SRVCC on LTE

The SRVCC handover process takes place in a number of steps:

  1. The handover process is initiated by a request for session transfer from the IMS CSCF.
  2. The IMS CSCF responds simultaneously with two commands, one to the LTE network, and the other to the legacy network.
  3. the LTE network receives a radio Access Network handover execution command through the MME and LTE RAN. This instructs the user device to prepare to move to a circuit switched network for the voice call.
  4. The destination legacy circuit switched network receives a session transfer response preparing it to accept the call from the LTE network.
  5. After all the commands have been executed and acknowledged the call is switched to the legacy network with the IMS CSCF still in control of the call.

Legacy network to LTE

When returning a call to the LTE network much of the same functionality is again used.

To ensure the VoLTE device is able to return to the LTE RAN from the legacy RAN, there are two options the legacy RAN can implement to provide a swift and effective return:

  • Allow LTE information to be broadcast on the legacy RAN so the LTE device is able to perform the cell reselection more easily.
  • Simultaneously release the connection to the user device and redirect it to the LTE RAN.

SRVCC interruption performance

One of the key issues with VoLTE and SRVCC is the interruption time when handing over from an LTE RAN to a legacy RAN.

The key methodology behind reducing he time is to simultaneous perform the redirections of RAN and session. In this way the user experience is maintained and the actual interruption time is not unduly noticeable.

It has been found that the session redirection is the faster of the two handovers, and therefore it is necessary for the overall handover methodology to accommodate the fact that there are difference between the two.


출처 

http://www.radio-electronics.com/info/cellulartelecomms/lte-long-term-evolution/srvcc-single-radio-voice-call-continuity.php

'Japan > Work As Tester' 카테고리의 다른 글

자주 등장하는 프로토콜 정리  (0) 2016.03.09
SRVCC의 종류  (0) 2016.03.09
SRVCC  (0) 2016.03.09
[설정]ADB 코멘드 사용 설정  (0) 2016.03.05
EVS란  (2) 2016.02.26
3GPP_Network 참고 사이트  (0) 2016.02.26

ADB코멘드를 사용하기 위해서

ADB코멘드를 사용하기 위해서는 Android SDK를 인스톨하여 설정할 필요가 있습니다. 
또한 Android SDK를 사용하기 위해서는 JDK(Java)를 인스톨할 필요가 있습니다. 

※SDK란, Software Development Kit의 줄임말로, 소프트웨어 개발에 필요한 것들이 들어있습니다. 

Android SDK에는 ADB, Bootloader, CWM에 사용하는 각종 드라이버가 포함되어있어, 인스톨하면 fastboot코멘드도 사용할 수 있게 됩니다. 

※PC의 관리자 권한이 아닌경우, 각 툴의 인스톨이 불가능할 수도 있습니다. 

 Java(JDK)のインストール

  1. Java SE - Downloads | Oracle Technology Network | Oracle」에서 「Java SE 8uX」(X는 버전 번호)의 란에있는「JDK DOWNLOAD」를 클릭

  2. Accept License Agreement」의 왼쪽이 있는 버튼을 클릭 하여 체크하고, 사용하고 있는 Windows의 버전에 맞는 것을 클릭하여, 다운로드. 
    (예:Windows 10 64bit판→jdk-8uXX-windows-x64.exe)
  3. 다운로드가 완료하면, 실행
  4. 「다음(N) >」을 클릭
  5. 인스톨할 경로는 필요한 경우, 변경 
    ※변경할 필요가 없는 경우 변경하지 않아도 괜찮음 
  6. 「소스・코드」의 좌측 아이콘을 클릭하여, 「해당 기능은, 사용 하지 않습니다. 」를 클릭하여 선택
  7. 동익하게 「퍼블릭 JRE」를 설정하여, 「개발 툴」이외에 인스톨하지 않도록한 후「다음(N) >」을 클릭함
  8. 인스톨이 완료될 때까지 기다림
  9. 닫음(C)」을 클릭

이상, Java(JDK)인스톨 완료! 

 Android SDK의 인스톨 및 설정

 Android SDK를 인스톨

  1. Download Android Studio and SDK Tools | Android Developers」에서, 하기에 있는「Other Download Options」의 「SDK Tools Only」에 있는 「Windows」란의 「installer_rXX.X.X-windows.exe」(X는 버전 번호)를 클릭하여 다운로드. 

  2. 확인 버전이 표시되므로, 「I have read and agree with the above terms and conditions」의 좌측을 클릭하여 체크한 후,「DOWNLOAD INSTALLER_RXX.X.X-WINDOWS.EXE」를 클릭하여 다운로드. 

  3. 다운로드 완료 후, 실시
  4. Next >」를 클릭
  5. Java(JDK)가 인스톨 되어있는 것을 확인하므로, 「Next >」를 클릭
  6. Install for anyone using this computer」의 왼쪽에 있는 버튼을 클릭한 후, 「Next >」를 클릭함 
  7. 필요한 경우 인스톨 경로를 변경, 필요없는 경우는 그대로「Next >」를 클릭
    ※그림에서는「D:\Program Files (x86)\Android\android-sdk」로 변경함
    ※이후 Path를 입력해야 하므로, 어디에 인스톨 했는지 경로를 기억해 두거나 복사해서 기록해 놓을 것 

  8. 시작 메뉴에 등록 여부를 확인하므로 확인 후「Install」을 클릭함

  9. 인스톨이 완료할때까지 기다림 

  10. 완료한 것을 확인한 후, 「Next >」를 클릭
  11. Finish」를 클릭
  12. 자동으로 「Android SDK Manager」가 기동됨 
  13. Android SDK Platform-tools」의 좌측 체크 버튼을 클릭 후 체크
  14. 가장 하단으로 스크롤 하여, 「Google USB Driver」의 좌측 버튼을 클릭하여 체크
  15. 그 외의 항목 전부(예:Android SDK Build-tools 등)의 체크를 해제하고,「Android SDK Platform-tools」와 「Google USB Driver」만 체크한 상태로 함
  16. Install 2 package...」가 표시되는 것을 확인한 후, 해당 버튼을 클릭
  17. Accept License」의 좌측 버튼을 클릭하여, 각 항목의 좌측에 초록색의 체크가 표시되는 것을 확인한 후, 「Install」을 클릭함 
  18. 인스톨이 완료될때까지 기다림 
  19. 「Done loading packages.」가 표시되는 것을 확인한 후, 「Close」를 클릭
    ※에러가 발생하는 경우는 다시한번 실행함 
  20. 닫음 버튼을 클릭한 후, 「Android SDK Manager」를 종료함
이상, Android SDK의 인스톨 방법임

 Android SDK의 설정

ADB코멘드는 Android SDK를 인스톨한 것만으로는 사용하는 것이 불가능합니다. 환경번수의 Path를 편집하여,「Path를 통과」시키는 작업이 필요합니다. 

해당 작업을 함으로써, 명령창에서 ADB 코맨드를 사용하는 것이 가능하게 됩니다. 

환경변수의 편집은 시스템의 동작에 영향을 줍니다! 틀리지 않도록 주의해 주세요!
  1. 데스크 탑 왼쪽 하단의 「스타트」버튼을 클릭하여, 「시스템」을 클릭

  2. 시스템의 상세설정」을 클릭

  3. 환경변수(N)...」를 클릭

  4. 「환경변수」화면이 표시되므로, 「시스템 환경변수(S)」란을 하단으로 스크롤하여, 변수「Path」를 클릭하여 선택한 후, 「편집(I)...」을 클릭

  5. 「환경변수명의 편집」화면이 표시되므로, 「신규(N)」를 클릭 함

  6. 입력란에 「Android SDK의 인스톨」방법의 7에서 결정한 「인스톨 장소」에「\platform-tools」을 추가함 Path명을 입력하여「Enter」키를 누름
    예:「D:\Program Files (x86)\Android\android-sdk」에 인스톨한 경우, 「D:\Program Files (x86)\Android\android-sdk\platform-tools」라 입력

  7. Path명이 정확히 입력된 것을 확인한 후, 「OK」를 클릭

  8. OK」를 클릭
  9. OK」를 클릭
  10. PC를 재기동한 후, 명령창을 염 

  11. adb」라고 입력 후, 「Enter」키를 누름 

  12. 하기의 그림과 같이 내용이 표시되어 adb코멘드가 동작하고 있는 것을 확인
이상, Android SDK의 설정방법임 

 참고:Windows 7에서의 Android SDK의 설정 

작업 내용 자체는 동일하나, Windows 7에서는 환경변수의 변경방법이 약간 다릅니다. 
  1. 데크스탑의 왼쪽 하단의 「스타트」버튼을 클릭한 후, 「컴퓨터」위에 포인트를 맞춘 후, 마우스 「오른쪽 클릭

  2. 속성」를 클릭

  3. 시스템 상세설정」을 클릭

  4. 「시스템 설정」화면이 표시되므로 「상세설정」탭을 클릭

  5. 환경변수(N)...」를 클릭

  6. 「환경변수」화면이 표시되므로 「시스템 환경변수(S)」란을 하단으로 스크롤한 하여, 변수「Path」를 클릭하여 「편집(I)...」을 클릭함

  7. 「시스템 변수의 편집」화면이 표시되므로, 「변수 값(V):」란의 가장 끝쪽(오른쪽)에,  Android SDK의 인스톨 방법의 7에서 결정한 「인스톨 장소+\platform-tools;」를 추가 기입
    예:「D:\Program Files (x86)\Android\android-sdk」에 인스톨→「D:\Program Files (x86)\Android\android-sdk\platform-tools;」를 추가※원래 적혀있는 경로는 환경에 따라 다릅니다. 절대로 덮어쓰기하지 않도록 주의해 주세요!
    ※각 Path의 마지막에는 반드시「;」를 붙여주어야 합니다. 추가기입 전, (원래 기입되어 있던 경로들)의 마지막 부분에 「;」가 없는 경우는 「;」를 기입한 후에 Path를 입력해 주세요. 

  8. 추가기입을 완료된 후, 「OK」를 클릭

  9. OK」를 클릭
  10. OK」를 클릭
  11. PC를 재기동한 후, 명령창을 염

  12. adb」를 입력한 후, 「Enter」키를 누름 
  13. 하기의 화면과 같은 내용이 표시되는 것을 확인 

이상, Windows 7에서 Android SDK의 설정 방법입니다. 

 드라이버의 인스톨 

실제로 코멘드를 사용하기 위해서는, 드라이버를 인스톨 하여 단말을 PC에 접속 시킬 필요가 있습니다. 


출처 http://andmem.blogspot.jp/2014/04/installjdkandroidsdkadb.html

'Japan > Work As Tester' 카테고리의 다른 글

SRVCC의 종류  (0) 2016.03.09
SRVCC  (0) 2016.03.09
[설정]ADB 코멘드 사용 설정  (0) 2016.03.05
EVS란  (2) 2016.02.26
3GPP_Network 참고 사이트  (0) 2016.02.26
3GPP  (0) 2016.02.26

+ Recent posts